| From: | Jean-Luc Lachance <jllachan(at)nsd(dot)ca> |
|---|---|
| To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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:50:11 |
| Message-ID: | 3F1D8763.4BE6DCD7@nsd.ca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
Hey! here is a (stupid maybe) idea. Why not disallow 'NaN' for a float?
JLL
Stephan Szabo wrote:
>
> 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 | Bruce Momjian | 2003-07-22 18:59:19 | Re: min() and NaN |
| Previous Message | Stephan Szabo | 2003-07-22 18:32:36 | Re: min() and NaN |