Dates & times:
I confirm that libc6 2.0.7pre1 cures all the time and date problems
that I was having with glibc2. So no patches are needed; just undefine
HAVE_INT_TIMEZONE for glibc2.
Int2, int4, oidint2, oidint4:
In the regression tests, for glibc2 we should expect to see 'Numerical
result out of range' rather than `Math result not representable'.
New with libc6 2.0.7:
Float4: some of the tests failed because glibc2 works _better_ than libc5!
One test involves inserting values of 10e-40. libc5 fails, but glibc2
says that 10e-40 is equivalent to 1e-39 and successfully inserts it.
It also stores larger numbers as Inf and -Inf and inserts these values rather
than failing. So many of the tests report 9 rows instead of 5.
Float8:
Again some tests work which didn't with libc5:
expected:
QUERY: UPDATE FLOAT8_TBL
SET f1 = FLOAT8_TBL.f1 * '-1'
WHERE FLOAT8_TBL.f1 > '0.0';
QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
ERROR: Bad float8 input format -- overflow
glibc2:
QUERY: SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
bad|?column?
---+----------------
|0
|-3.484e+201
|-1.0043e+203
|Infinity
|-1.2345678901234
(5 rows)
On the other hand, this no longer works:
expected:
QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
bad| ?column?
---+--------------------
| 1
|7.39912306090513e-16
| 0
| 0
| 1
(5 rows)
glibc2:
QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
ERROR: exp() result is out of range
geometry:
results from converting circles to polygons are still different by about
3e-12 on some co-ordinates.
triggers:
I think the expected results are wrong:
I get (among other differences):
QUERY: insert into fkeys2 values (70, '5', 3);
ERROR: check_fkeys2_pkey_exist: tuple references non-existing key in pkeys
which is not in the expected results but looks right.
select-views:
many differences, but I believe these are also seen on other platforms.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
