From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Richard Broersma <richard(dot)broersma(at)gmail(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Subqueries in Check() -- Still Intentionally Omitted? |
Date: | 2008-09-06 19:30:57 |
Message-ID: | 200809061930.m86JUvM23081@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> "Richard Broersma" <richard(dot)broersma(at)gmail(dot)com> writes:
> > I am curious if the motivation is still valid for intentionally
> > omitting check sub-queries. (what was the motivation to begin with?)
>
> > Since we can effectively work around this limitation by doing the same
> > thing with a function in a CHECK constraint, why would we want to
> > prevent anyone from using the standard syntax for achieving the same
> > effect?
>
> Because if we supported the standard syntax, we'd also have to support
> the standard semantics; which a function-in-CHECK does *not* give you.
>
> The standard says that the constraint is guaranteed not to be violated,
> which in the worst case means that any time you update the table(s)
> referenced in the subquery, you have to retest the CHECK expression
> at every row of the table having the constraint. Consider for instance
> CREATE TABLE t1 (x int CHECK (x < (SELECT sum(y) FROM t2)));
> If we change some value of t2.y, do all values of t1.x still satisfy
> their constraint?
>
> In some cases, with enough intelligence you could optimize this into
> something fast enough to be usable; but it's a research problem.
> (The cases that I can see how to optimize are pretty much equivalent to
> plain foreign key constraints, anyway.)
Is this a TODO? I assume it is not.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-06 20:54:24 | Re: recover in single-user backend fails |
Previous Message | Jorge Godoy | 2008-09-06 18:25:41 | Re: storing repeating dates / events |