From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200307221614.h6MGEfc23097@candle.pha.pa.us>
Subject: Re: min() and NaN
In-Reply-To: <4074.1058854149@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 22 Jul 2003 12:14:41 -0400 (EDT)
Cc: 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


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.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Is this a TODO?
> 
> It'll only take ten minutes to make it a DONE, once we figure out what
> the behavior ought to be.  So far I think both Stephan and I argued that
> MIN/MAX ought to treat NaN as larger than all ordinary values, for
> consistency with the comparison operators.  That was not the behavior
> Michael wanted, but I don't see that we have much choice given the
> wording of the SQL spec.  Does anyone want to argue against that
> definition?
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  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