On Sun, 20 Jul 2003, Tom Lane wrote:
> "Michael S. Tibbetts" <mtibbetts@head-cfa.cfa.harvard.edu> writes:
> > I'd expect the aggregate function min() to return the minimum, valid
> > numeric value. Instead, it seems to return the minimum value from the
> > subset of rows following the 'NaN'.
>
> Not real surprising given than min() is implemented with float8smaller,
> which does this:
>
> result = ((arg1 > arg2) ? arg1 : arg2);
>
> In most C implementations, any comparison involving a NaN will return
> "false". So when we hit the NaN, we have arg1 = min so far, arg2 = NaN,
> comparison yields false, result is NaN. On the next row, we have
> arg1 = NaN, arg2 = next value, comparison yields false, result is next
> value; and away it goes.
>
> We could probably make it work the way you want with explicit tests for
> NaN in float8smaller, arranged to make sure that the result is not NaN
> unless both inputs are NaN. But I'm not entirely convinced that we
> should make it work like that. The other float8 comparison operators
> are designed to treat NaN as larger than every other float8 value (so
> that it has a well-defined position when sorting), and I'm inclined to
> think that float8smaller and float8larger probably should behave
> likewise. (That actually is the same as what you want for MIN(), but
> not for MAX() ...)
The spec seems to say that min/max should work the same way as the
comparison operators by saying that it returns the maximum or minimum
value as determined by the comparison rules of the comparison predicate
section. That'd seem to be asking for the second version.
