Adrian Klaver <aklaver@xxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
