Tom Lane wrote: > "Richard Broersma" <richard.broersma@xxxxxxxxx> 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
