On Mon, Aug 21, 2000 at 04:37:21PM -0400, Tom Lane wrote:
> "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.
Oh really? Then why do btree's have their own comparator functions,
seperate from heap sorts, and datum sorts, and explicit use of '<' ? The
current code infrastructure allows for the possibility that these may need
to diverge, requiring the coders to keep them in sync. Annoying, that, but
useful for edge cases.
Since btree already uses it's own comparator, The only reason I can
see that the parser drops in '<' and '>' as the name of the sorting
operator to use for ORDER BY is convenience: the functions are there,
and have the (mostly) correct behavior.
Changing this would only require writing another set of operators for
the parser to drop in, that are used only for sorting, so that the
sort behavior could diverge slightly, by knowing how to sort NULLs and
NaNs. Yes, it'd be a third set of operators to keep in sync with the
btree and default ones, but it could give completely correct behavior.
Hmm, I another thought: all the comparator code assumes (a<b || a>b || a==c)
and therefor only test 2 of the three conditions, falling through to the
third. In the three places I just looked, two fall thorough to the equal case,
and one to the 'less than' case. If all three fell through to the 'greater than'
case, it might work with no tweaking at all. I'll have to try that, first.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005