Date: Tue, 12 Nov 2002 08:30:30 -0800 (PST)
From: Stephan Szabo <sszabo@megazone23.bigpanda.com>
To: =?iso-8859-1?Q?C=E9dric_Dufour_=28Cogito_Ergo_Soft=29?=
	<cedric.dufour@cogito-ergo-soft.com>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: Efficient ON DELETE trigger when referential integrity is
In-Reply-To: <NDBBIFNBODNADCAOFDOACECECEAA.cedric.dufour@cogito-ergo-soft.com>
Message-ID: <20021112082305.V67144-100000@megazone23.bigpanda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 12 Nov 2002, [iso-8859-1] C=E9dric Dufour (Cogito Ergo Soft) wrote:

> Hello,
>
> I am trying to figure out how to handle tuple deletion efficiently when ON
> DELETE triggers and referential integrity are involved. The scenario is
> about this one:
>
> I have a MASTER and a SLAVE table, the latter referencing the former thro=
ugh
> a "FOREIGN KEY ... REFERENCES ... ON DELETE CASCADE" constraint. Besides,=
 I
> have a ON DELETE trigger on the SLAVE table which updates a field in the
> MASTER table upon deletion.
>
> Now, there no need to update the MASTER table if the SLAVE table deletion
> was actually fired by the FOREIGN KEY constraint. The ON DELETE trigger
> updates a tuple in the MASTER table which will be deleted itself right
> after. This can make the deletion of a MASTER table tuple very slow, if
> there are a lot of related tuples in the SLAVE table.
>
> Is there any "by the book" way to handle this ?

Hmm, by the time that the on delete trigger runs after the foreign key
action, I believe that the row in MASTER is already gone.  Running a
simple test in 7.3 seems to confirm this.  Unfortunately it's still going
to look for the row to update it.  I can't think of a good way to tell
if you're in an action that was caused by a foreign key rather than some
other user trigger or rule or straight delete apart from some vague
notions of really complicated workarounds which only partially help.