Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Le lundi 25 ao�t 2008, Gregory Stark a �crit�:
>> I'm not sure it's made explicit anywhere in the documentation but those
>> properties *are* what btree operator classes define. You would end up
>> duplicating the same structures (like, LT is meaningless unless you
>> associate it with the corresponding EQUALITY, LE, GT, and GE operators).
> But, IIRC, only in the context of index searches, not at the planner level.
No, that's not true at all. There are lots and lots of places now where
we use btree and/or hash operator classes to reason about the properties
of operators. The most in-your-face example right now is ORDER BY: if
you say ORDER BY x, that's gonna fail outright unless x's type has a
default btree opclass. And if it does, the < member of the opclass is
what defines the sort order.
So we have certainly set some precedents involving using opclasses to
make semantic choices. What's really bothering me is that we aren't
consistent about it: some things like ORDER BY are opclass-driven,
and some things like BETWEEN are operator-name-driven.
regards, tom lane
