Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group