Le 27 févr. 2010 à 17:57, Tom Lane a écrit :
> =?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara(at)mac(dot)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;
>> (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... :-(
In response to
pgsql-hackers by date
|Next:||From: Greg Smith||Date: 2010-02-27 18:17:42|
|Subject: Re: Lock Wait Statistics (next commitfest)|
|Previous:||From: Tom Lane||Date: 2010-02-27 16:57:31|
|Subject: Re: NaN/Inf fix for ECPG |