Re: unsafe floats - Mailing list pgsql-hackers

From Neil Conway
Subject Re: unsafe floats
Date
Msg-id 87llm8s5r9.fsf@mailbox.samurai.com
Whole thread Raw
In response to unsafe floats  (Dennis Bjorklund <db@zigo.dhs.org>)
Responses Re: unsafe floats  (Dennis Bjorklund <db@zigo.dhs.org>)
Re: unsafe floats  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Dennis Bjorklund <db@zigo.dhs.org> 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: selective statement logging
Next
From: Andrew Dunstan
Date:
Subject: Re: selective statement logging