| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jean-Luc Lachance <jllachan(at)nsd(dot)ca>, "Michael S(dot) Tibbetts" <mtibbetts(at)head-cfa(dot)cfa(dot)harvard(dot)edu>, <pgsql-sql(at)postgresql(dot)org> |
| Subject: | Re: min() and NaN |
| Date: | 2003-07-22 18:32:36 |
| Message-ID: | 20030722112906.M39399-100000@megazone.bigpanda.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
On Tue, 22 Jul 2003, Bruce Momjian wrote:
> Well, my 2 cents is that though we consider NULL when ordering via ORDER
> BY, we ignore it in MAX because it really isn't a value, and NaN seems
> to be similar to NULL.
>
> When doing ORDER BY, we have to put the NULL value somewhere, so we put
> it at the end, but with aggregates, we aren't required to put the NULL
> somewhere, so we ignore it. Should that be the same for NaN? I just
> don't see how we can arbitrarly say it is greater/less than other
> values.
But we already do. When doing a less than/greater than comparison, 'NaN'
is considered greater than normal values which is different from NULL
which returns unknown for both.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jean-Luc Lachance | 2003-07-22 18:50:11 | Re: min() and NaN |
| Previous Message | Markus Bertheau | 2003-07-22 17:56:58 | Re: slow query |