Re: Trigger before delete does fire before, but delete doesn't not happen

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adrian Klaver <aklaver(at)comcast(dot)net>
Cc: " Stéphane A(dot) Schildknecht" <stephane(dot)schildknecht(at)postgresqlfr(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Trigger before delete does fire before, but delete doesn't not happen
Date: 2008-12-01 18:53:56
Message-ID: 24220.1228157636@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Adrian Klaver <aklaver(at)comcast(dot)net> writes:
> The problem as far as I can tell is tuple visibility.

Sort of: the triggers on commandeligne fire (and update the commande row)
at completion of the DELETE command inside p_commande_bd. This means
that by the time control returns from that trigger, the tuple version
that was targeted for deletion is already dead, so there's nothing to
do. It doesn't chain up to the newer version of the row.

An AFTER trigger would be better for this on general principles, anyway.
The rule of thumb is "use a BEFORE trigger to adjust what happens to the
target row, but use an AFTER trigger to propagate the changes to other
rows". If you don't do it that way then you have problems whenever
there are multiple triggers, since no individual BEFORE trigger can be
sure it knows the final state of the row.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2008-12-01 19:38:05 Re: [HACKERS] Reg: Nested query
Previous Message Vignesh Raaj 2008-12-01 18:39:23 Reg: Nested query