Re: Boolean operators without commutators vs. ALL/ANY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Boolean operators without commutators vs. ALL/ANY
Date
Msg-id 22916.1307936691@sss.pgh.pa.us
Whole thread Raw
In response to Re: Boolean operators without commutators vs. ALL/ANY  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Boolean operators without commutators vs. ALL/ANY
Re: Boolean operators without commutators vs. ALL/ANY
Re: Boolean operators without commutators vs. ALL/ANY
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Boolean operators without commutators vs. ALL/ANY
Next
From: Robert Haas
Date:
Subject: Re: Range Types and extensions