Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> When UNSAFE_FLOATS is defined there is a check that float results
> are within the min and max limits, which excludes values like
> 'Infinity', '-Infinity' and 'Nan'.
No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
is defined or not.
> At first I thought it was a bug, but this function that checks for
> overflow wouldn't even be needed if not to stop such values.
Well, CheckFloat4Val() is needed to ensure that the input fits in a
'float' (rather than just a 'double').
> Should I go ahead and make it accept 'Infinity' and the rest as
> numbers?
What number would you like 'Infinity'::float4 and 'Infinity'::float8
to produce? Is this actually useful functionality?
As for it being in the SQL standard, using Acrobat's "text search"
feature finds zero instances of "infinity" (case insensitive) in the
200x draft spec. I haven't checked any more thoroughly than that,
though.
My inclination is to get rid of UNSAFE_FLOATS entirely, and disallow
'Infinity' and '-Infinity' input to float8 (since it never worked to
begin with, and float4 doesn't accept those values either). But I'm
open to other comments.
-Neil
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
