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
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 |