On 22 March 2015 at 14:46, Bruce Momjian <br...@momjian.us> wrote: > On Wed, Mar 18, 2015 at 05:52:44PM -0400, Bruce Momjian wrote: > > In September, while researching the to_char() buffer overflow bugs fixed > > in 9.4.1 (commit 0150ab567bcf5e5913e2b62a1678f84cc272441f), I found an > > inconsistency in how to_char() does zero-padding for float4/8 values. > > Now that 9.4.1 is released and I am home for a while, I am ready to > > address this. > ... > > float4/8 are padding to the internal precision, while int4/numeric are > > padding based on the requested precision. This is inconsistent. > > > > The first attached patch fixes this, and also zeros the "junk" digits > > which exceed the precision of the underlying type: > > Patch applied. > > This seems to have broken jacana. Looks like MSVC by default has a 3 digit exponent.
Going by this: https://msdn.microsoft.com/en-us/library/0fatw238(v=vs.80).aspx it seems that it can quite easily be set back to 2. I've attached a patch which seems to fix the issue. Regards David Rowley
diff --git a/src/backend/main/main.c b/src/backend/main/main.c index 2f07a58..51f0884 100644 --- a/src/backend/main/main.c +++ b/src/backend/main/main.c @@ -262,8 +262,16 @@ startup_hacks(const char *progname) /* In case of general protection fault, don't show GUI popup box */ SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX); } + #endif /* WIN32 */ +#ifdef _MSC_VER + + /* By default MSVC has a 3 digit exponent. */ + _set_output_format(_TWO_DIGIT_EXPONENT); + +#endif /* _MSC_VER */ + /* * Initialize dummy_spinlock, in case we are on a platform where we have * to use the fallback implementation of pg_memory_barrier().
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers