Re: How PostgreSQL's floating-point hurts everyone everywhere

> What happened?

This may be platform-specific behavior. I see on my Linux/Mandrake box
the following:

lockhart=# select 'nan'::float8;
ERROR: Bad float8 input format -- overflow
lockhart=# select 'infinity'::float8;
ERROR: Bad float8 input format -- overflow

Typically, machines will trap overflow/underflow/NaN problems in
floating point, but silently ignore these properties with integer
arithmetic. It would be nice to have consistant behavior across all
types, but I'll stick to floats for discussion now.

Lots of machines (but not all) now support IEEE arithmetic. On those
machines, istm that we can and should support some of the IEEE
conventions such as NaN and +Inf/-Inf. But on those machines which do
not have this concept, we can either try to detect this during data
entry, or trap this explicitly during floating point exceptions, or
watch the backend go up in flames (which would be the default behavior).

Same with divide-by-zero troubles.

> I think the CheckFloat{4,8}Val() functions should be abandoned and the
> floating point results should be allowed to overflow to +Infinity or
> underflow to -Infinity. There also need to be isinf() and isnan()
> functions, because surely "x = 'infinity'" isn't going to work.

It does work if "infinity" is first interpreted by our input routines.

I recall running into some of these issues when coding some data
handling routines on my late, great Alpha boxes. In this case, I tried
to use the isinf() (??) routine provided by DEC (and defined in IEEE?)
to test for bad values coming from a real-time GPS tracking system. But
until I futzed with the compiler options, calling isinf() failed on any
infinity value since the value was being checked during the call to the
routine, so the value was never getting to the test!

> This is not a high-priority issue to me, nor do I feel particularly
> qualified on the details, but at least we might agree that something's
> wrong.

I'd think that, on some platforms, we can try coding things a bit
differently. But the code in there now does do some useful things for
some of the platforms we run on (though there are still holes in
possible failure modes). imho if we change things it would be to turn
some of the checking into NOOP macros on some platforms, but preserve
these for others.

- Thomas