From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Boolean operators without commutators vs. ALL/ANY |
Date: | 2011-06-13 03:44:51 |
Message-ID: | 22916.1307936691@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug <fgp(at)phlo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-13 04:00:08 | Re: Range Types and extensions |
Previous Message | Robert Haas | 2011-06-13 03:12:58 | Re: Boolean operators without commutators vs. ALL/ANY |