Greg Stark <gsst...@mit.edu> writes:
> I'm not sure that solves the problem because the "default" gist
> operator class isn't necessarily going to be the one with the
> strategies this needs,
Forgot to mention: I do not think default-ness of opclasses enters
into it at all. The meaning of the query is fully defined by the
operator that is in it. All we need to know is what are the
semantics of that operator. If we can find it in the "overlaps"
position of *any* opclass, we are entitled to suppose that it
behaves like overlaps and the associated left-of operator can be
used to optimize it. Conceivably we could get different left-of
operators out of different opclasses, but if they don't behave
effectively the same, the user has messed up the opclasses.
As an example, suppose we are trying to implement DISTINCT via
sort-and-unique, and we've chosen an appropriate '=' operator that
defines what distinct-ness means. That operator might appear in more
than one opclass having more than one sort order, but it doesn't matter
which one we choose. As long as the opclasses are self-consistent,
we should get correct answers with any one.
The case where default-ness of opclasses matters is where we are
trying to assign specific meaning to some generic construct like
DISTINCT or ORDER BY. For instance, it makes sense to require
that ORDER BY be interpreted by reference to a default opclass,
because otherwise you don't have a way to know which sort ordering
the user wants.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
