Horton
Menu

Re: NaN/Inf fix for ECPG

Rémi Zara <remi_zara@mac.com>

View thread
From: Rémi Zara <remi_zara@mac.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Boszormenyi Zoltan <zb@cybertec.at>, Michael Meskes <meskes@postgresql.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-02-27T13:40:13Z
Lists: pgsql-hackers 
Le 26 févr. 2010 à 17:11, Tom Lane a écrit :

> =?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara@mac.com> writes:
>> I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because strtod("NaN", endptr) works. (isnan(strtod("NaN", endptr)) is true).
> 
> Hmm.  So what do you get from
> 	SELECT 'nan'::numeric::float8;
> on that machine?  That should exercise the backend's version of
> get_float8_nan().
> 


regression=# select 'nan'::numeric::float8;
  float8  
----------
 Infinity
(1 row)

So it is indeed the same behavior. Maybe that should be added to the regression tests.
So what's the best way to workaround the bug in NetBSD/mips ? (nan(""), (0.0/0.0), strtod("nan", null) ?)

Regards,

Rémi Zara