From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200307221859.h6MIxJk11503@candle.pha.pa.us>
Subject: Re: min() and NaN
In-Reply-To: <20030722112906.M39399-100000@megazone.bigpanda.com>
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Date: Tue, 22 Jul 2003 14:59:19 -0400 (EDT)
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jean-Luc Lachance <jllachan@nsd.ca>,
	"Michael S. Tibbetts" <mtibbetts@head-cfa.cfa.harvard.edu>,
	pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073