Re: NaN/Inf fix for ECPG - Mailing list pgsql-hackers

From Tom Lane
Subject Re: NaN/Inf fix for ECPG
Date
Msg-id 26148.1267289851@sss.pgh.pa.us
Whole thread Raw
In response to Re: NaN/Inf fix for ECPG  (Rémi Zara <remi_zara@mac.com>)
Responses Re: NaN/Inf fix for ECPG
List pgsql-hackers
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?

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Lock Wait Statistics (next commitfest)
Next
From: Rémi Zara
Date:
Subject: Re: NaN/Inf fix for ECPG