Thread: Re: ECPGset_var
Hi, Michael Meskes írta: > Zoltan, could you please look into this: > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugong&dt=2010-01-26%2011:05:01 ? > Apparently dugong creates the ECPGset_var statements in a different order than > the other archs. > > Michael > It seems mongoose also fails the same way, the common factor seems to be ICC, other machines with various GCC versions are green . I'll look into it. 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/
Boszormenyi Zoltan <zb@cybertec.at> writes: > Michael Meskes írta: >> Zoltan, could you please look into this: >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugong&dt=2010-01-26%2011:05:01 ? >> Apparently dugong creates the ECPGset_var statements in a different order than >> the other archs. > It seems mongoose also fails the same way, > the common factor seems to be ICC, other machines > with various GCC versions are green . I'll look into it. The problem is you've got calls like this: $$ = cat_str(4, adjust_outofscope_cursor_vars(this, true), adjust_outofscope_cursor_vars(this, false), make_str("ECPG_informix_reset_sqlca();"), comment); in which the order of evaluation of cat_str's parameters is unspecified, but adjust_outofscope_cursor_vars has got order-dependent side effects. regards, tom lane
Tom Lane írta: > Boszormenyi Zoltan <zb@cybertec.at> writes: > >> Michael Meskes Ărta: >> >>> Zoltan, could you please look into this: >>> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugong&dt=2010-01-26%2011:05:01 ? >>> Apparently dugong creates the ECPGset_var statements in a different order than >>> the other archs. >>> > > >> It seems mongoose also fails the same way, >> the common factor seems to be ICC, other machines >> with various GCC versions are green . I'll look into it. >> > > The problem is you've got calls like this: > > $$ = cat_str(4, > adjust_outofscope_cursor_vars(this, true), > adjust_outofscope_cursor_vars(this, false), > make_str("ECPG_informix_reset_sqlca();"), > comment); > > in which the order of evaluation of cat_str's parameters is unspecified, > but adjust_outofscope_cursor_vars has got order-dependent side effects. > > regards, tom lane > > Thanks for analyzing it, patch is attached. I downloaded and installed ICC, so I could reproduce the difference. Also, another "bug" is fixed in one regression test, it seems NaN is different across platforms, so we must not test for it either. 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/
Attachment
Boszormenyi Zoltan wrote:
> Thanks for analyzing it, patch is attached. I downloaded
> and installed ICC, so I could reproduce the difference.
Why not have a single function that does both things in a single call?
It doesn't look like there's any place that calls the function with only
one value for "insert" ...
I happened to notice this misleading comment:
char temp[20]; /* this should be sufficient unless you have 8 byte integers */
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera írta: > Boszormenyi Zoltan wrote: > > >> Thanks for analyzing it, patch is attached. I downloaded >> and installed ICC, so I could reproduce the difference. >> > > Why not have a single function that does both things in a single call? > It doesn't look like there's any place that calls the function with only > one value for "insert" ... > Okay, I tried this approach, patch is attached. This way it doesn't depend on the evaluation order of function parameters. > I happened to notice this misleading comment: > > char temp[20]; /* this should be sufficient unless you have 8 byte integers */ > That comment was there before I touched that function, I deleted it now. There will be other problems before reaching 2^31-1 internal variables, like compiling the monster C file without the compiler going OOM... 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/
Attachment
Boszormenyi Zoltan wrote: > Alvaro Herrera írta: > > I happened to notice this misleading comment: > > > > char temp[20]; /* this should be sufficient unless you have 8 byte integers */ > > > > That comment was there before I touched that function, I deleted it now. > There will be other problems before reaching 2^31-1 internal variables, > like compiling the monster C file without the compiler going OOM... No, I meant alvherre=# select length((2^32)::text), length((2^64)::text);length | length --------+-------- 10 | 20 (1 fila) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Boszormenyi Zoltan <zb@cybertec.at> writes:
> Also, another "bug" is fixed in one regression test,
> it seems NaN is different across platforms, so
> we must not test for it either.
Really? The main regression tests have several test cases for NaN,
and no provision that I can see for platform dependence of the
result.
-- special inputs
SELECT 'NaN'::float8;float8
-------- NaN
(1 row)
If ecpg isn't handling this maybe you have a real bug to deal with.
regards, tom lane
Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>
>> Also, another "bug" is fixed in one regression test,
>> it seems NaN is different across platforms, so
>> we must not test for it either.
>>
>
> Really? The main regression tests have several test cases for NaN,
> and no provision that I can see for platform dependence of the
> result.
>
> -- special inputs
> SELECT 'NaN'::float8;
> float8
> --------
> NaN
> (1 row)
>
> If ecpg isn't handling this maybe you have a real bug to deal with.
>
> regards, tom lane
>
>
I meant this, e.g. from "gypsy_moth":
===================================
*** /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.11494/src/interfaces/ecpg/test/expected/preproc-outofscope.stdout
Tue Jan 26 13:51:59 2010
--- /export/home/tmp/pg-test/build-suncc/HEAD/pgsql.11494/src/interfaces/ecpg/test/results/preproc-outofscope.stdout
TueJan 26 14:14:58 2010
***************
*** 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 '
===================================
This is the result of a printf(). My Fedora 9 writes out "nan",
every Sparc machine in the buildfarm writes out "NaN".
This is not an ECPG parser bug, only a difference in the
system libc.
However, on "mastodon", a Windows Server 2003 machine:
===================================
--- 92,96 ---- [NO_PID]: sqlca: code: 0, state: 00000 [NO_PID]: ecpg_get_data on line 49: RESULT: NaN offset: -1;
array:yes [NO_PID]: sqlca: code: 0, state: 00000
! [NO_PID]: raising sqlcode -206 on line 49: invalid input syntax for floating-point type: "NaN", on line 49
! [NO_PID]: sqlca: code: -206, state: 42804
===================================
This comes from this code in data.c, in ecpg_get_data():
case ECPGt_float: case ECPGt_double:
if (isarray && *pval == '"') dres = strtod(pval + 1,
&scan_length); else dres =
strtod(pval,
&scan_length);
if (isarray && *scan_length == '"')
scan_length++;
if (garbage_left(isarray,
scan_length, compat)) {
ecpg_raise(lineno,
ECPG_FLOAT_FORMAT,
ECPG_SQLSTATE_DATATYPE_MISMATCH, pval); return (false);
}
It seems Windows doesn't accept "NaN" in strtod(). Is it really the 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/
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
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/
Hi, Boszormenyi Zoltan írta: > 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. > the attached patch attempts to fix NaN/Infinity problems in ECPG for float/double/numeric/decimal. I had to introduce a new NUMERIC_NULL value for the numeric sign to still be able to use risnull()/rsetnull(). 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/