Re: ECPGset_var

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

In response to

Responses

Browse pgsql-hackers by date

  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