Re: min() and NaN

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
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:59:19
Message-ID: 200307221859.h6MIxJk11503@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

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.

But maybe that logic is the same as ORDER BY, where we have to give it
some location in sorting order, while with aggregates we don't.

I am not strong on this, but just point it out.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2003-07-22 19:33:19 Re: min() and NaN
Previous Message Jean-Luc Lachance 2003-07-22 18:50:11 Re: min() and NaN