Re: Boolean operators without commutators vs. ALL/ANY

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

In response to

Responses

Browse pgsql-hackers by date

  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