Re: IN, BETWEEN, spec compliance, and odd operator names

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Gregory Stark <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: IN, BETWEEN, spec compliance, and odd operator names
Date: 2008-08-25 14:48:19
Message-ID: 20257.1219675699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Le lundi 25 aot 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-08-25 15:10:54 Re: temporary statistics option at initdb time
Previous Message Alvaro Herrera 2008-08-25 14:43:40 Re: can't stop autovacuum by HUP'ing the server