| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | "Michael S(dot) Tibbetts" <mtibbetts(at)head-cfa(dot)harvard(dot)edu> |
| Cc: | <pgsql-sql(at)postgresql(dot)org> |
| Subject: | Re: min() and NaN |
| Date: | 2003-07-20 06:11:34 |
| Message-ID: | 20030719230117.X55138-100000@megazone.bigpanda.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
On Tue, 15 Jul 2003, Michael S. Tibbetts wrote:
> Hi,
>
> I have a table containing a double precision column. That column
> contains at least one judiciously placed NaN.
>
> 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'.
This appears to be a bug in the min (and presumably max) aggregate
function for floats. AFAICT It should use the same logic as the < (or >)
comparison operator for the type (SQL92 6.5 GR2b iii I believe), but it's
just doing a < (or >) in C on the two arguments which isn't the same.
Changing it to follow those rules would give 2.718 for min and it looks
like NaN for max.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2003-07-20 06:15:01 | Re: changing an update via rules |
| Previous Message | Chris Travers | 2003-07-20 05:07:34 | SECURITY DEFINER changes CURRENT_USER? |