Date: Sat, 14 Oct 2006 19:07:26 -0600
From: Michael Fuhr <mike@fuhr.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL SQL List <pgsql-sql@postgresql.org>,
	Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>
Subject: Re: Foreign key reference counting strategy?
Message-ID: <20061015010725.GA21149@winnie.fuhr.org>
References: <1160828741.28838.9.camel@panoramix>
	<4530EB84.4050904@logix-tt.com>
	<20061014234844.GA20342@winnie.fuhr.org>
	<13525.1160870286@sss.pgh.pa.us>
	<20061015001126.GA20713@winnie.fuhr.org>
	<13667.1160871610@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <13667.1160871610@sss.pgh.pa.us>

On Sat, Oct 14, 2006 at 08:20:10PM -0400, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > Unless the inserters got there first.  I just tested both ways; if
> > the insert acquires the lock first then the delete fails, but if the
> > delete acquires the lock first then the insert fails.
> 
> Well, if the inserters get a lock on the PK row before the DELETE does,
> then of course.  I was just disputing the assertion that doing IF EXISTS
> in an after trigger would add a new way for the DELETE to fail.

My intent wasn't to assert that IF EXISTS adds a new way for the
DELETE to fail.  I was just pointing out that the test "if no
referencing rows exist then delete the referenced row" isn't
foolproof, viz., the DELETE can fail even though IF EXISTS said
there were no referencing rows.

-- 
Michael Fuhr