Date: Mon, 22 Mar 2004 17:21:21 +0100
From: Erik Thiele <erik@thiele-hydraulik.de>
To: Bruno Wolff III <bruno@wolff.to>
Cc: pgsql-sql@postgresql.org
Subject: Re: special integrity constraints
Message-Id: <20040322172121.72ecf58b.erik@thiele-hydraulik.de>
In-Reply-To: <20040322151211.GA2962@wolff.to>
References: <20040322102031.6a6f0b77.erik@thiele-hydraulik.de>
	<20040322112604.GA31222@wolff.to>
	<20040322141042.0aeb936d.erik@thiele-hydraulik.de>
	<20040322151211.GA2962@wolff.to>
Organization: Thiele-Hydraulik
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 22 Mar 2004 09:12:11 -0600
Bruno Wolff III <bruno@wolff.to> wrote:

> On Mon, Mar 22, 2004 at 14:10:42 +0100,
>   Erik Thiele <erik@thiele-hydraulik.de> wrote:
> > 
> > it means (((count_rows(a)+count_rows(b)) modulo 2) == 0)
> 
> OK, that means my FK suggestion won't help. The other suggestion about
> putting triggers on "a" and "b" to update a count in another table
> that has a deferred check constraint on it may be your best bet.
> This will be a source of contention, but that may or may not be all
> that important depending on how often you are updating "a" and "b".
> 

there is no such thing as a deferred check constraint:

DEFERRABLE
NOT DEFERRABLE

This controls whether the constraint can be deferred. A constraint that
is not deferrable will be checked immediately after every command.
Checking of constraints that are deferrable may be postponed until the
end of the transaction (using the SET CONSTRAINTS command). NOT
DEFERRABLE is the default. 

!!! Only foreign key constraints currently accept
this clause. All other constraint types are not deferrable. !!!


cu
erik

-- 
Erik Thiele