On Sun, Mar 22, 2015 at 01:42:56AM -0400, Tom Lane wrote:
> David Rowley <dgrowle...@gmail.com> writes:
> > This seems to have broken jacana. Looks like MSVC by default has a 3 digit
> > exponent.
>
> jacana was broken before this patch; but some other Windows critters
> are now unhappy as well.
>
> > Going by this:
> > https://msdn.microsoft.com/en-us/library/0fatw238(v=vs.80).aspx it seems
> > that it can quite easily be set back to 2.
>
> > I've attached a patch which seems to fix the issue.
>
> That seems likely to have side-effects far beyond what's appropriate.
> We have gone out of our way to accommodate 3-digit exponents in other
> tests. What I want to know is why this patch created a 3-digit output
> where there was none before.
I was wondering the same thing too, but when I grep'ed the regression
output files looking for exponents, I found float4-exp-three-digits.out
and int8-exp-three-digits.out. I think this means we have had this
issue before, and we are going to have to either create a
numeric-exp-three-digits.out alternate output file, move the test to one
of the existing exp-three-digits files, or remove the tests. Sorry, I
didn't expect any problems with this patch as it was so small and
localized.
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.
--
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
