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

From Bruce Momjian
Subject Re: Zero-padding and zero-masking fixes for to_char(float)
Date
Msg-id 20150323024954.GA19951@momjian.us
Whole thread Raw
In response to Re: Zero-padding and zero-masking fixes for to_char(float)  (Noah Misch <noah@leadboat.com>)
Responses Re: Zero-padding and zero-masking fixes for to_char(float)
List pgsql-hackers
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. +



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: debug_sortsupport GUC?
Next
From: Bruce Momjian
Date:
Subject: Re: Zero-padding and zero-masking fixes for to_char(float)