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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: IN, BETWEEN, spec compliance, and odd operator names
Дата
Msg-id 12281.1219694479@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: IN, BETWEEN, spec compliance, and odd operator names  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: IN, BETWEEN, spec compliance, and odd operator names
Следующее
От: Peter Schuller
Дата:
Сообщение: Implementing cost limit/delays for insert/delete/update/select