Prev: Dividing progress/debug information in pg_standby, and stat before copy
Next: Review of Writeable CTE Patch
From: Alvaro Herrera on 26 Jan 2010 15:14
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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 26 Jan 2010 15:40
Boszormenyi Zoltan <zb(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Boszormenyi Zoltan on 26 Jan 2010 15:55
Tom Lane �rta:
> Boszormenyi Zoltan <zb(a)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 Tue Jan 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/


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 26 Jan 2010 16:03
Boszormenyi Zoltan <zb(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Boszormenyi Zoltan on 26 Jan 2010 18:14
Tom Lane �rta:
> Boszormenyi Zoltan <zb(a)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/


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Dividing progress/debug information in pg_standby, and stat before copy
Next: Review of Writeable CTE Patch