From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ECPGset_var |
Date: | 2010-01-26 21:03:10 |
Message-ID: | 19580.1264539790@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Boszormenyi Zoltan <zb(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2010-01-26 22:55:01 | Re: Patch: libpq new connect function (PQconnectParams) |
Previous Message | Boszormenyi Zoltan | 2010-01-26 20:55:22 | Re: ECPGset_var |