From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pre-proposal: type interfaces |
Date: | 2009-10-23 20:40:44 |
Message-ID: | 1256330444.28858.135.camel@monkey-cat.sm.truviso.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-23 21:55:30 | Re: pre-proposal: type interfaces |
Previous Message | Tom Lane | 2009-10-23 20:25:26 | Re: pre-proposal: type interfaces |