From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)hub(dot)org |
Subject: | Re: Re: [GENERAL] +/- Inf for float8's |
Date: | 2000-08-21 20:37:21 |
Message-ID: | 6931.966890241@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
>>>> or add another ordering operator that is only used for the sort case
>>>> (use of '>' and '<' seems to be hardcoded all the way to the parser)
>>
>> don't even think about that...
> Sure, but any ideas _how_ to get 'NaN > +Infinity' to happen only during a
> sort operation, and not when '>' is called explicity as a WHERE condition,
> by touching only type specific code?
That's exactly what you shouldn't even think about. The entire index
and sorting system is predicated on the assumption that '<' and related
operators agree with the order induced by a btree index. You do not get
to make the operators behave differently in the free-standing case than
when they are used with an index.
> 'Cause I'd call it a bug to be able to say:
> SELECT * from foo where f8 > 'Infinity';
> and get anything at all back.
I agree it's pretty arbitrary to define NaN as > Infinity, but the sort
ordering is necessarily arbitrary. We can special-case NULL because
that's a type-independent concept, but special-casing NaN is out of the
question IMHO. Pick where you want it in the type-specific order, and
live with it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vince Vielhaber | 2000-08-21 20:37:42 | Re: Bug tracking (was Re: +/- Inf for float8's) |
Previous Message | The Hermit Hacker | 2000-08-21 20:32:01 | Re: Bug tracking (was Re: +/- Inf for float8's) |