Le 27 févr. 2010 à 17:57, Tom Lane a écrit :
> Rémi Zara <remi_zara@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?
>
I submitted it.
> BTW, what about the float4 case, 'nan'::numeric::float4 ?
That works OK.
>
>> 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.
>
It would mean retiring pika until/if the bug is fixed... :-(
Regards,
Rémi Zara
