On Sun, Mar 22, 2015 at 12:46:08PM -0400, Noah Misch wrote:
> On Sun, Mar 22, 2015 at 11:22:26AM -0400, Bruce Momjian wrote:
> > What has me more concerned is the Solaris 10 failure. This query:
> >
> > SELECT to_char(float8 '99999999999', '9999999999999999D' || repeat('9', 1000));
> >
> > expects this:
> >
> > 99999999999.00000000000...
> >
> > but on Solaris 10 gets this:
> >
> > .000000000000000000
> >
> > Yes, the nines are gone, and only this query is failing. Oddly, this
> > query did not fail, though the only difference is fewer decimal digits:
> >
> > SELECT to_char(float8 '99999999999', '9999999999999999D99999999');
> >
> > This smells like a libc bug, e.g. OmniOS 5.11 passed the test.
>
> Use of the "f" conversion specifier with precision greater than 512 is not
> portable; I get a similar diff on AIX 7. Until this patch, PostgreSQL would
> not use arbitrarily-large precisions on that conversion specifier. (Who would
> guess, but the "e" conversion specifier is not affected.)
Yeah.
> I recommend adding a "configure" test to use our snprintf.c replacements if
> sprintf("%.*f", 65536, 99999999999.0) gives unexpected output.
Do we really want to go to our /port snprintf just to handle 512+
digits?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
