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

From Noah Misch
Subject Re: Zero-padding and zero-masking fixes for to_char(float)
Date
Msg-id 20150322164608.GA790880@tornado.leadboat.com
Whole thread Raw
In response to Re: Zero-padding and zero-masking fixes for to_char(float)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Zero-padding and zero-masking fixes for to_char(float)
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.



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: PATCH: numeric timestamp in log_line_prefix
Next
From: Воронин Дмитрий
Date:
Subject: Re: New functions