Re: Re: [PATCHES] Patch for PostgreSQL 7.0.3 to compile on Tru64 UNIX v5.0A

Alessio Bragadini <alessio(at)albourne(dot)com> writes:
> Tom Lane wrote:
>> Sounds good; could you check the regress tests too?

> *** ./expected/float8-fp-exception.out Thu Mar 30 10:46:00 2000
> --- ./results/float8.out Tue Apr 17 20:09:17 2001
> ***************
> *** 214,220 ****
> SET f1 = FLOAT8_TBL.f1 * '-1'
> WHERE FLOAT8_TBL.f1 > '0.0';
> SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
> ! ERROR: floating point exception! The last floating point operation either exceeded legal ranges or was a divide by zero
> SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
> ERROR: pow() result is out of range
> SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
> --- 214,220 ----
> SET f1 = FLOAT8_TBL.f1 * '-1'
> WHERE FLOAT8_TBL.f1 > '0.0';
> SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
> ! ERROR: Bad float8 input format -- overflow
> SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
> ERROR: pow() result is out of range
> SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;

That's fairly strange. It doesn't seem to have a problem with the
constant '1e200' as such --- notice that the next query gets the
expected result. But why would we get "Bad float8 input format"
for a calculation-result overflow? Ideas anyone?

regards, tom lane