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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: IN, BETWEEN, spec compliance, and odd operator names
Date: 2008-08-25 20:01:19
Message-ID: 12281.1219694479@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote:
>> To me the issue is what we consider IN and BETWEEN and similar
>> constructs to "mean", which in a datatype world boils down to choosing
>> which of the datatype's operators to implement the construct with.

> I was thinking the problem was using real operator names. Here we make
> up an unambiguous name that is not currently in use that can be
> resolved to the required operator on demand.

No, I don't think that really helps anything. The parser would just
immediately move to the next step of trying to resolve the operator,
so you've only introduced another bit of notation without actually
solving any problems. The issue of concern here is *how* to identify
the required operator, not exactly when/where it happens.

> If you define the lookup to always match the type of the left-hand
> value you can force consistant semantics. Whether its the semantics you
> want is another question.

Probably not, since it would fail outright in cases where the LHS has
to be promoted in order to get a match (such as my int4 vs numeric
example). We've allowed that in the past, so rejecting it would
probably be a hard sell.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Schuller 2008-08-25 20:39:07 Implementing cost limit/delays for insert/delete/update/select
Previous Message Martijn van Oosterhout 2008-08-25 19:54:06 Re: IN, BETWEEN, spec compliance, and odd operator names