Re: Re: [GENERAL] +/- Inf for float8's
От | Tom Lane |
---|---|
Тема | Re: Re: [GENERAL] +/- Inf for float8's |
Дата | |
Msg-id | 6931.966890241@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [GENERAL] +/- Inf for float8's ("Ross J. Reedstrom" <reedstrm@rice.edu>) |
Ответы |
Re: Re: [GENERAL] +/- Inf for float8's
|
Список | pgsql-hackers |
"Ross J. Reedstrom" <reedstrm@rice.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
В списке pgsql-hackers по дате отправления: