From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)hub(dot)org |
Subject: | Re: Re: [GENERAL] +/- Inf for float8's |
Date: | 2000-08-23 06:23:46 |
Message-ID: | 26931.967011826@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Allan Huffman | 2000-08-23 06:41:32 | How Do You Pronounce "PostgreSQL" |
Previous Message | Thomas Lockhart | 2000-08-23 06:17:40 | New MAC OUI capabilities |