X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 04F9DD1C50F
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 22 Jul 2003 19:33:28 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
	by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new,
	port 10024) with ESMTP id 85769-09
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 22 Jul 2003 16:32:43 -0300 (ADT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by svr1.postgresql.org (Postfix) with ESMTP id 191B0D1C50C
	for <pgsql-sql@postgresql.org>; Tue, 22 Jul 2003 16:33:26 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h6MJXJQ3015161;
	Tue, 22 Jul 2003 15:33:19 -0400 (EDT)
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>,
	Jean-Luc Lachance <jllachan@nsd.ca>,
	"Michael S. Tibbetts" <mtibbetts@head-cfa.cfa.harvard.edu>,
	pgsql-sql@postgresql.org
Subject: Re: min() and NaN 
In-reply-to: <200307221859.h6MIxJk11503@candle.pha.pa.us> 
References: <200307221859.h6MIxJk11503@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
	message dated "Tue, 22 Jul 2003 14:59:19 -0400"
Date: Tue, 22 Jul 2003 15:33:19 -0400
Message-ID: <15160.1058902399@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200307/327
X-Sequence-Number: 14441

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 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.

Good idea, but I don't think we can get away with it.  The spec says
that MAX/MIN have to be consistent with the comparison operators (and
therefore with ORDER BY):

            iii) If MAX or MIN is specified, then the result is respec-
                 tively the maximum or minimum value in TXA. These results
                 are determined using the comparison rules specified in
                 Subclause 8.2, "<comparison predicate>".

NULL can be special, because it acts specially in comparisons anyway.
But NaN is just a value of the datatype.

I'd be willing to go against the spec if I thought that having
ignore-NaNs behavior was sufficiently important, but I don't think it's
important enough to disregard the spec...

			regards, tom lane