"Jim Buttafuoco" <jim@contactbda.com> writes:
> All I want to do is add a check in CheckFloat4Val for infinity (and remove the
> individual checks before the CheckFloat4Val call in other routines).
That's not at all what you proposed before, and it would have vastly
more side-effects than just removing the platform-dependent behavior
you are on about. If we did that then this would work:
regression=# select ('infinity'::float4) / (1::float4);
ERROR: type "real" value out of range: overflow
... which arguably it ought to, but you'd be changing the behavior
everywhere not just for your broken compiler.
I think the real question we ought to face up to sometime is what it is
we are trying to accomplish with CheckFloat4Val and CheckFloat8Val in
the first place. The latter routine in particular seems pretty
ill-advised to me: if something can be represented as a double then why
don't we just allow it?
ISTM that what we really want is to reject out-of-range results, as in
these examples:
regression=# select (1e37::float4) / (1e-37::float4);
ERROR: type "real" value out of range: overflow
regression=# select (1e300::float8) / (1e-37::float8);
ERROR: type "double precision" value out of range: overflow
regression=#
On machines that have IEEE infinity, I think it would work to report
overflow if the result is infinity when neither input is. But I dunno
how well that works on non-IEEE hardware. Also, what about rejecting
NaN results? Thoughts anyone?
regards, tom lane