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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers