new int8 test still has problems
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
SELECT CAST(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
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;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 correct result 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("bigint out 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