On Jun13, 2011, at 05:44 , Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Jun 12, 2011 at 7:46 AM, Florian Pflug <fgp@phlo.org> wrote:
>>> (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.
Hm, OK, I get that.
> (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.)
Yeah, I never expected non-immutable CHECK constraints to work. I was
simply pointing out that UNNEST() allows one to write all kinds of
interesting CHECK constraints, all of which are immutable.
Now, if supporting these would increase code complexity, or cause
a performance drop for non-sub-query CHECK constraints, I'm perfectly
fine with leaving them unsupported. I just wanted to make sure we
aren't simply nannying the user - especially since it's a nanny who's
out-smarted by function calls.
best regards,
Florian Pflug
