Re: NaN/Inf fix for ECPG

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rémi Zara <remi_zara(at)mac(dot)com>
Cc: Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: NaN/Inf fix for ECPG
Date: 2010-02-27 16:57:31
Message-ID: 26148.1267289851@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara(at)mac(dot)com> writes:
> Le 26 fvr. 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rémi Zara 2010-02-27 17:18:10 Re: NaN/Inf fix for ECPG
Previous Message Tom Lane 2010-02-27 16:44:28 Re: Lock Wait Statistics (next commitfest)