> On Tue, Aug 22, 2000 at 08:22:21PM +0200, Peter Eisentraut wrote:
>> Hmm, I'm getting the feeling that perhaps at this point we should
>> explicitly *not* support NaN at all.
Well ... this is a database, not a number-crunching system. It seems
to me that we should be able to store and retrieve NaNs (at least on
IEEE-compliant platforms). But I'm less excited about whether the
sorting/comparison operators we offer are 100% IEEE-compliant.
It has been quite a few years since I looked closely at the IEEE FP
specs, but I do still recall that they made a distinction between "IEEE
aware" and "non IEEE aware" comparison operators --- specifically, the
first kind understood about unordered comparisons and the second didn't.
Perhaps we could satisfy both SQL and IEEE requirements if we stipulate
that we implement only IEEE's "non-aware" comparisons? Worth looking at
anyway.
>> ... hard-core floating point users are going to fail miserably
>> with the FE/BE protocol anyway.
It would be a mistake to design backend behavior on the assumption that
we'll never have an FE/BE protocol better than the one we have today.
(You could actually fix this problem without any protocol change,
just a SET variable to determine output precision for FP values.
Well-written platforms will reproduce floats exactly given "%.17g"
or more precision demand in sprintf. If that fails it's libc's
bug not ours.)
regards, tom lane