Re: Zero-padding and zero-masking fixes for to_char(float) - Mailing list pgsql-hackers

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.