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-21 17:39:32 |
Message-ID: | 3777.966879572@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> While examining the output from ORDER BY queries, both using and not using
> an index, I came across a discrepancy: the explicit handling of NULLs in
> the tuplesort case always sorts NULLs to the end, regardless of direction
> of sort.
Yeah. I think that's widely considered a bug --- we have a TODO item to
fix it. You might care to dig in the archives for prior discussions.
> To make the direct sort the same as the index read would work for NULL,
> but for NaN would either require allowing NaN to be returned as >
> Infinity, which doesn't happen now,
Seems to me the sort order should be
-Infinity
normal values
+Infinity
other types of NaN
NULL
and the reverse in a descending sort.
> or add another ordering operator that is only used for the sort case
> (use of '>' and '<' seems to be hardcoded all the way to the parser)
don't even think about that...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2000-08-21 17:47:41 | Re: Bug tracking (was Re: +/- Inf for float8's) |
Previous Message | Adam Haberlach | 2000-08-21 17:28:18 | Re: Bug tracking (was Re: +/- Inf for float8's) |