Обсуждение: new int8 test still has problems

Поиск
Список
Период
Сортировка

new int8 test still has problems

От
Tom Lane
Дата:
It fails on two of my machines like this:

*** src/test/regress/expected/int8.out    Sun Oct  5 12:19:58 2008
--- src/test/regress/results/int8.out    Sun Oct  5 12:20:26 2008
***************
*** 748,756 **** (1 row)  SELECT CAST('9223372036854775807.0'::float4 AS int8);
! ERROR:  bigint out of range SELECT CAST('9223372036854775807.0'::float8 AS int8);
! ERROR:  bigint out of range SELECT CAST('922337203685477580700.0'::float8 AS int8); ERROR:  bigint out of range
SELECTCAST(q1 AS oid) FROM INT8_TBL;
 
--- 748,764 ---- (1 row)  SELECT CAST('9223372036854775807.0'::float4 AS int8);
!         int8         
! ---------------------
!  9223372036854775807
! (1 row)
!  SELECT CAST('9223372036854775807.0'::float8 AS int8);
!         int8         
! ---------------------
!  9223372036854775807
! (1 row)
!  SELECT CAST('922337203685477580700.0'::float8 AS int8); ERROR:  bigint out of range SELECT CAST(q1 AS oid) FROM
INT8_TBL;

======================================================================

It seems to me that these two new tests are inherently checking
machine-dependent floating point behavior, not anything Postgres
can control.  I'd suggest just removing them.

The buildfarm is showing still other "interesting" behaviors.
I'm not really interested in having umpteen expected int8 files
to deal with all the strange corner cases that might be seen
on different platforms.  Please just remove all the edge-case
tests.
        regards, tom lane

Re: new int8 test still has problems

От
Peter Eisentraut
Дата:
Tom Lane wrote:
> The buildfarm is showing still other "interesting" behaviors.
> I'm not really interested in having umpteen expected int8 files
> to deal with all the strange corner cases that might be seen
> on different platforms.  Please just remove all the edge-case
> tests.

Yeah, it's probably not worth bother too much with them.  I have removed 
the problem cases.

This result from AIX/PPC can't be good, however:

***************
*** 684,690 ****  select '9223372036854775800'::int8 * '100'::int4;  ERROR:  bigint out of range  select
'-9223372036854775808'::int8/ '-1'::int4;
 
! ERROR:  bigint out of range  select '100'::int4 + '9223372036854775800'::int8;  ERROR:  bigint out of range  select
'-100'::int4- '9223372036854775800'::int8;
 
--- 688,698 ----  select '9223372036854775800'::int8 * '100'::int4;  ERROR:  bigint out of range  select
'-9223372036854775808'::int8/ '-1'::int4;
 
!  ?column?
! ----------
!         0
! (1 row)
!  select '100'::int4 + '9223372036854775800'::int8;  ERROR:  bigint out of range  select '-100'::int4 -
'9223372036854775800'::int8;

Re: new int8 test still has problems

От
Tom Lane
Дата:
Peter Eisentraut <peter_e@gmx.net> writes:
> This result from AIX/PPC can't be good, however:

Hmm.  The test in int84div is
   /*    * Overflow check.    The only possible overflow case is for arg1 =    * INT64_MIN, arg2 = -1, where the
correctresult is -INT64_MIN, which    * can't be represented on a two's-complement machine.    */   if (arg2 == -1 &&
arg1< 0 && result < 0)       ereport(ERROR,               (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("bigintout of range")));
 

Maybe we could use "result <= 0" for the third check?  Surely a zero
result cannot be correct given the first two checks.

The other integer division functions should be looked at too.
        regards, tom lane