On Fri, 2009-10-23 at 16:25 -0400, Tom Lane wrote:
> 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.
Interesting, that sounds we've got a good approach to the problem now.
This thread has been useful.
> 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.
It would probably be worthwhile to make an attempt to throw a useful
error there, but I agree it's not really a problem.
> 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.
That makes sense.
Thanks,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
