Re: ECPGset_var - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: ECPGset_var
Date
Msg-id 4B5F7746.6080508@cybertec.at
Whole thread Raw
In response to Re: ECPGset_var  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ECPGset_var  (Boszormenyi Zoltan <zb@cybertec.at>)
List pgsql-hackers
Tom Lane írta:
> 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).
>   

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/



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Next
From: "Joshua D. Drake"
Date:
Subject: Re: plpython3