| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: Re: [GENERAL] +/- Inf for float8's |
| Date: | 2001-06-02 20:50:03 |
| Message-ID: | Pine.LNX.4.30.0106022243150.23690-100000@peter.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane writes:
> [ continuing a discussion from last August ]
[I was *just* thinking about this. Funny.]
> I believe that's not a problem anymore. The current form of the float
> comparison functions will perform sorting and comparisons according to
> the sequence
>
> -infinity < normal values < infinity < NaN < NULL
I was thinking about making NaN equivalent to NULL. That would give
consistency in ordering, and probably also in arithmetic. Additionally,
if the platform supports it we ought to make the Invalid Operation FP
exception (which yields NaN) configurable: either get NULL or get an
error.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-06-02 21:11:00 | Re: Re: [GENERAL] +/- Inf for float8's |
| Previous Message | Tom Lane | 2001-06-02 20:31:27 | Re: Re: [GENERAL] +/- Inf for float8's |