Re: ECPGset_var
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Michael Meskes <meskes@postgresql.org>, PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Date: 2010-01-26T21:03:10Z
Lists: 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