From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Neil Conway <neilc(at)samurai(dot)com> |
Subject: | Re: unsafe floats |
Date: | 2004-03-10 22:13:28 |
Message-ID: | 13346.1078956808@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dennis Bjorklund <db(at)zigo(dot)dhs(dot)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'.
> Is the above something from the SQL standard or just a bug?
I think it was probably reasonable when the code was written (I'd guess
this goes back to very early 90s). Nowadays, IEEE float math is nearly
universal, and we would be offering better functionality if we allowed
access to Infinity and Nan by default. So I'd vote for ripping out the
range check, or at least reversing the default state of UNSAFE_FLOATS.
We might end up with two sets of regression expected files, one for
machines that do not support NaN, but that seems acceptable to me.
A variant idea is to try to get configure to detect Infinity/NaN support
and set UNSAFE_FLOATS only if it's there. But I don't know if we can do
that without a run-time check, which Peter probably will complain about...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-03-10 22:20:24 | Re: selective statement logging |
Previous Message | Andrew Dunstan | 2004-03-10 21:51:25 | Re: selective statement logging |