| 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: | Whole Thread | Raw Message | 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 |