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
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 |