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

From Rémi Zara
Subject Re: NaN/Inf fix for ECPG
Date
Msg-id CAC0E717-9B5E-4261-AEC1-35C8BBA24E24@mac.com
Whole thread Raw
In response to Re: NaN/Inf fix for ECPG  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: NaN/Inf fix for ECPG
List pgsql-hackers
Le 26 févr. 2010 à 17:11, Tom Lane a écrit :

> Rémi 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

pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Lock Wait Statistics (next commitfest)
Next
From: "Dickson S. Guedes"
Date:
Subject: Re: caracara failing to bind to localhost?