Re: Re: [GENERAL] +/- Inf for float8's

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

In response to

Responses

Browse pgsql-hackers by date

  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)