Re: ECPGset_var - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ECPGset_var
Date
Msg-id 19580.1264539790@sss.pgh.pa.us
Whole thread Raw
In response to Re: ECPGset_var  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: ECPGset_var  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> writes:
> Tom Lane �rta:
>> Really?  The main regression tests have several test cases for NaN,
>> and no provision that I can see for platform dependence of the
>> result.

> I meant this, e.g. from "gypsy_moth":

> *** 1,4 ****
>   id=1 t='a' d1=1.000000 d2=2.000000 c = 'a         '
>   id=2 t='' (NULL) d1=0.000000 (NULL) d2=0.000000 (NULL) c = '' (NULL)
> ! id=3 t='"a"' d1=-1.000000 d2=nan c = 'a         '
>   id=4 t='b' d1=2.000000 d2=3.000000 c = 'b         '
> --- 1,4 ----
>   id=1 t='a' d1=1.000000 d2=2.000000 c = 'a         '
>   id=2 t='' (NULL) d1=0.000000 (NULL) d2=0.000000 (NULL) c = '' (NULL)
> ! id=3 t='"a"' d1=-1.000000 d2=NaN c = 'a         '
>   id=4 t='b' d1=2.000000 d2=3.000000 c = 'b         '

Hmm.  The backend gets around this by testing isnan() rather than
relying on what sprintf will do with a NaN.  I'm not sure if it's
possible/practical for ecpg to do likewise.  Even if it's not, it
might be better to carry a variant result file instead of not testing
NaN behavior at all.  I'll leave it to Michael to make that decision
though ...

> It seems Windows doesn't accept "NaN" in strtod(). Is it really the case?

Again, see the backend (float8in).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: ECPGset_var
Next
From: Guillaume Lelarge
Date:
Subject: Re: Patch: libpq new connect function (PQconnectParams)