- 14 6月, 2012 1 次提交
-
-
由 Tom Lane 提交于
This includes fixing the MSVC copy of ecpg/preproc's version info, which seems to have been overlooked repeatedly. Can't we fix that so there are not two copies??
-
- 11 6月, 2012 1 次提交
-
-
由 Bruce Momjian 提交于
commit-fest.
-
- 24 4月, 2012 1 次提交
-
-
由 Robert Haas 提交于
Josh Kupershmidt
-
- 08 4月, 2012 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 16 3月, 2012 1 次提交
-
-
由 Peter Eisentraut 提交于
The tzn value might come from tm->tm_zone, which libc declares as const, so it's prudent that the upper layers know about this as well.
-
- 15 3月, 2012 1 次提交
-
-
由 Peter Eisentraut 提交于
Use an explicit argument to tell whether to include the time zone in the output, rather than using some undocumented pointer magic.
-
- 02 1月, 2012 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 19 12月, 2011 1 次提交
-
-
由 Michael Meskes 提交于
-
- 11 12月, 2011 1 次提交
-
-
由 Andrew Dunstan 提交于
Remove some dead code, conditionally declare some items or call some code, and fix one or two declarations.
-
- 19 6月, 2011 1 次提交
-
-
由 Magnus Hagander 提交于
Since we now have a global rule in the root .gitignore, there's no need to keep directory-specific ones as well. Noted by Peter Eisentraut
-
- 10 6月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 11 5月, 2011 1 次提交
-
-
由 Tom Lane 提交于
Normally nel == 0 works okay because the initial value of "last" will be less than "base"; but if "base" is zero then the calculation wraps around and we have a very large (unsigned) value for "last", so that the loop can be entered and we get a SIGSEGV on a bogus pointer. This is certainly the proximate cause of the recent reports of Windows builds crashing on 'infinity'::timestamp --- evidently, they're either not setting an active timezonetktbl, or setting an empty one. It's not yet clear to me why it's only happening on Windows and not happening on any buildfarm member. But even if that's due to some bug elsewhere, it seems wise for this function to not choke on the powerup values of timezonetktbl/sztimezonetktbl. I also changed the copy of this code in ecpglib, although I am not sure whether it's exposed to a similar hazard. Per report and stack trace from Richard Broersma.
-
- 29 4月, 2011 1 次提交
-
-
由 Andrew Dunstan 提交于
Per recent -hackers discussion. The formats in question are %G and %V, and cause warnings on MinGW at least. We assume the ecpg application knows what it's doing if it passes these formats to the library.
-
- 20 4月, 2011 1 次提交
-
-
由 Peter Eisentraut 提交于
-
- 02 1月, 2011 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 22 9月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
-
- 21 9月, 2010 1 次提交
-
-
由 Magnus Hagander 提交于
-
- 17 8月, 2010 1 次提交
-
-
由 Michael Meskes 提交于
-
- 02 8月, 2010 1 次提交
-
-
由 Tom Lane 提交于
interval input "invalid" was specified together with other fields. Spotted by Neil Conway with the help of a clang warning. Although this has been wrong since the interval code was written more than 10 years ago, it doesn't affect anything beyond which error message you get for a wrong input, so not worth back-patching very far.
-
- 13 7月, 2010 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 16 6月, 2010 1 次提交
-
-
由 Peter Eisentraut 提交于
constant format strings, so that the compiler can more easily check the formats for correctness.
-
- 09 5月, 2010 2 次提交
-
-
由 Tom Lane 提交于
My initial impression that glibc was measuring the precision in characters (which is what the Linux man page says it does) was incorrect. It does take the precision to be in bytes, but it also tries to truncate the string at a character boundary. The bottom line remains the same: it will mess up if the string is not in the encoding it expects, so we need to avoid %.*s anytime there's a significant risk of that. Previous code changes are still good, but adjust the comments to reflect this knowledge. Per research by Hernan Gonzalez.
-
由 Tom Lane 提交于
Depending on which spec you read, field widths and precisions in %s may be counted either in bytes or characters. Our code was assuming bytes, which is wrong at least for glibc's implementation, and in any case libc might have a different idea of the prevailing encoding than we do. Hence, for portable results we must avoid using anything more complex than just "%s" unless the string to be printed is known to be all-ASCII. This patch fixes the cases I could find, including the psql formatting failure reported by Hernan Gonzalez. In HEAD only, I also added comments to some places where it appears safe to continue using "%.*s".
-
- 03 2月, 2010 1 次提交
-
-
由 Michael Meskes 提交于
Patch done by Zoltán Böszörményi.
-
- 03 1月, 2010 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 03 9月, 2009 1 次提交
-
-
由 Michael Meskes 提交于
-
- 07 8月, 2009 1 次提交
-
-
由 Michael Meskes 提交于
based on a patch send in by Böszörményi Zoltán <zb@cybertec.at>.
-
- 13 7月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 11 6月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
provided by Andrew.
-
- 26 5月, 2009 1 次提交
-
-
由 Tom Lane 提交于
-
- 21 5月, 2009 2 次提交
-
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
-
- 22 3月, 2009 1 次提交
-
-
由 Tom Lane 提交于
noise words for the last twelve years, for compatibility with Berkeley-era output formatting of the special INVALID values for those datatypes. Considering that the datatypes themselves have been deprecated for awhile, this is taking backwards compatibility a little far. Per gripe from Josh Berkus.
-
- 05 2月, 2009 1 次提交
-
-
由 Michael Meskes 提交于
-
- 04 2月, 2009 1 次提交
-
-
由 Michael Meskes 提交于
-
- 02 2月, 2009 1 次提交
-
-
由 Michael Meskes 提交于
-
- 02 1月, 2009 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 27 11月, 2008 2 次提交
-
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
interval style into ecpg.
-
- 18 7月, 2008 1 次提交
-
-
由 Alvaro Herrera 提交于
-