Tom Lane <[EMAIL PROTECTED]> writes:
> NULL can be special, because it acts specially in comparisons anyway.
> But NaN is just a value of the datatype.
Does postgres intend to support all the different types of NaN? Does you
intend to have +Inf and -Inf and underflow detection and all the other g
Greg Stark <[EMAIL PROTECTED]> writes:
> Does postgres intend to support all the different types of NaN? Does you
> intend to have +Inf and -Inf and underflow detection and all the other goodies
> you actually need to make it useful?
We have some of that; it needs work, and it's always going to be
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
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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.
Bruce Momjian <[EMAIL PROTECTED]> 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 h
Stephan Szabo wrote:
>
> On Tue, 22 Jul 2003, Bruce Momjian wrote:
>
> > 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 N
Hey! here is a (stupid maybe) idea. Why not disallow 'NaN' for a float?
JLL
Stephan Szabo wrote:
>
> On Tue, 22 Jul 2003, Bruce Momjian wrote:
>
> > 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
On Tue, 22 Jul 2003, Bruce Momjian wrote:
> 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 a
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
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 compar
Is this a TODO?
---
Tom Lane wrote:
> Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> > If a compare with NaN is always false, how about rewriting it as:
> > result = ((arg1 < arg2) ? arg2 : arg1).
>
> That just changes the
Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> If a compare with NaN is always false, how about rewriting it as:
> result = ((arg1 < arg2) ? arg2 : arg1).
That just changes the failure mode.
regards, tom lane
---(end of broadcast)-
If a compare with NaN is always false, how about rewriting it as:
result = ((arg1 < arg2) ? arg2 : arg1).
Or better yet, swap arg1 and arg2 when calling float8smaller.
Use flaost8smaller( current_min, value).
JLL
Tom Lane wrote:
>
> "Michael S. Tibbetts" <[EMAIL PROTECTED]> writes:
> > I'd expe
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 min
On Sun, 20 Jul 2003, Tom Lane wrote:
> "Michael S. Tibbetts" <[EMAIL PROTECTED]> 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 surprisi
"Michael S. Tibbetts" <[EMAIL PROTECTED]> 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 float8s
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'.
Wh
17 matches
Mail list logo
