Re: Boolean operators without commutators vs. ALL/ANY

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Boolean operators without commutators vs. ALL/ANY
Дата
Msg-id 22916.1307936691@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Boolean operators without commutators vs. ALL/ANY  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Boolean operators without commutators vs. ALL/ANY  (Robert Haas <robertmhaas@gmail.com>)
Re: Boolean operators without commutators vs. ALL/ANY  (Florian Pflug <fgp@phlo.org>)
Re: Boolean operators without commutators vs. ALL/ANY  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug <fgp@phlo.org> wrote:
>> (B) There should be a way to use ANY()/ALL() with the
>> array elements becoming the left arguments of the operator.

> It seems to me that if we provided some way of handling this, your
> first proposal would be moot; and I have to say I like the idea of
> allowing this a lot more than tinkering with the operator names.

There are syntactic reasons not to do that.  It'd be a lot easier just
to provide a commutator operator for ~.

>> (C) Why do we forbid sub-queries in CHECK constraints?

> Dunno.  Maybe it's just an implementation restriction?

(1) We don't want to invoke the planner in the places where we'd
have to do so to make that work.

(2) It's just about inevitable that a sub-query would have results
dependent on other rows beside the one being checked.  As such, it
would be trying to enforce semantics that you simply can't enforce
via CHECK.  (And yes, you can bypass that with a function, but guess
what: it still won't actually work.)
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Boolean operators without commutators vs. ALL/ANY
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Range Types and extensions