Re: ECPGset_var

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Meskes <meskes(at)postgresql(dot)org>
Cc: PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ECPGset_var
Date: 2010-01-26 23:14:14
Message-ID: 4B5F7746.6080508@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane írta:
> 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).
>

Yes, I saw it and also looked at numeric_in() and compared
them with ecpg/pgtypeslib/numeric.c and NUMERIC_NAN
is not set anywhere. Also tested 'nan'::numeric and getting it into
a "numeric" variable gave me this:

! [NO_PID]: ecpg_get_data on line 49: RESULT NaN; errno 302
[NO_PID]: sqlca: code: 0, state: 00000
+ [NO_PID]: raising sqlcode -207 on line 49: SQL error -207 on line 49
+ [NO_PID]: sqlca: code: -207, state: 42804

errno == 302 (PGTYPES_NUM_BAD_NUMERIC) is set by pgtypeslib
and the subsequent error (-207 == ECPG_NUMERIC_FORMAT) has
a documentation bug at
http://www.postgresql.org/docs/8.4/interactive/ecpg-errors.html

I think the best would be to delete the NAN test from outofscope.pgc
and fix the double/numeric NaN/Inf/-Inf problem separately and have
their own test case.

Best regards,
Zoltán Böszörményi

--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2010-01-26 23:23:38 Re: plpython3
Previous Message Greg Smith 2010-01-26 23:03:55 Re: Dividing progress/debug information in pg_standby, and stat before copy