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.)
I recommend adding a "configure" test to use our snprintf.c replacements if
sprintf("%.*f", 65536, 99999999999.0) gives unexpected output.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
