=?iso-8859-1?Q?R=E9mi_Zara?= <remi_z...@mac.com> writes:
> Le 26 févr. 2010 à 17:11, Tom Lane a écrit :
>> Hmm. So what do you get from
>> SELECT 'nan'::numeric::float8;
> regression=# select 'nan'::numeric::float8;
> float8
> ----------
> Infinity
> (1 row)
> So it is indeed the same behavior.
Yeah. So what it boils down to is that the platform has a NAN constant
but casting it to double produces the wrong thing. There's no doubt
that that's a bug in the floating-point support. You did say you'd
submitted it to the NetBSD folk right?
BTW, what about the float4 case, 'nan'::numeric::float4 ?
> Maybe that should be added to the regression tests.
Perhaps. A lot of this stuff was never stress-tested in the past
because when it was put in, it was a crap shoot whether NaN (or Inf)
really worked on most platforms. Our attitude was "if it works for you,
great, but we're not going to sweat about it if it doesn't". I'm not
sure whether full IEEE float support has gotten sufficiently universal
to justify expecting more. I guess we could try it and see how many
other buildfarm members fail.
> So what's the best way to workaround the bug in NetBSD/mips ?
I don't think it's our bug to fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
