Treating NaN's as larger(or smaller) than all ordinary values seems a fine way to go.
It avoids the situation where you request MIN and get an ordinary value which is greater than the minimum ordinary value in the table. If MIN(or MAX given the ordering you're suggesting) returns NaN, the user would stand better odds of figuring out that something about the query needs to be changed. Returning an plausible, though possibly incorrect, ordinary value from MIN or MAX if there are NaN's in the column can lead users to make some unfortunate mistakes(voice of experience?). Thanks for your help, Mike > Bruce Momjian <[EMAIL PROTECTED]> 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly