X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C0DFFD7F8B for ; Tue, 6 Sep 2005 01:25:14 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 17400-04 for ; Tue, 6 Sep 2005 04:25:10 +0000 (GMT) Received: from megazone.bigpanda.com (megazone.bigpanda.com [64.147.171.210]) by svr1.postgresql.org (Postfix) with ESMTP id A95E2D826E for ; Tue, 6 Sep 2005 01:25:08 -0300 (ADT) Received: by megazone.bigpanda.com (Postfix, from userid 1001) id 6989E354EB; Mon, 5 Sep 2005 21:25:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by megazone.bigpanda.com (Postfix) with ESMTP id 67DEA354DF; Mon, 5 Sep 2005 21:25:08 -0700 (PDT) Date: Mon, 5 Sep 2005 21:25:08 -0700 (PDT) From: Stephan Szabo To: rdkennedy@acm.org Cc: pgsql-sql@postgresql.org Subject: Re: Table Constraint CHECK(SELECT()) alternative? In-Reply-To: <4319F05A.30300@fnal.gov> Message-ID: <20050905211839.U4939@megazone.bigpanda.com> References: <4319F05A.30300@fnal.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200509/53 X-Sequence-Number: 22600 On Sat, 3 Sep 2005, Robert D. Kennedy wrote: > I have seen in another thread that sub-queries in a CHECK > constraint have implementation ramifications that make them awkward to > implement and support. OK, fair enough, c'est la vie. > > ERROR: cannot use subquery in check constraint > > is the result. I have a model which seems to BEG for just such a feature > though. What alternatives are there to the use of CHECK(SELECT()) in > this model? The simplest thing is to place the select into a function and use a check constraint on that (with appropriate row locks). However, that won't prevent removal or change of a referenced row. You can use triggers to prevent that (in your case to prevent removal or change of id of a referenced node or the change of type of a referenced mode away from directory). At that point, you might be just as well off using a trigger to do the initial check as well.