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

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

On Tuesday 02 December 2008 3:19:11 am Stéphane A. Schildknecht wrote:
> Tom Lane a écrit :
> > Adrian Klaver <aklaver(at)comcast(dot)net> writes:
> >> Thanks for the explanation. Just so I am clear,the act of updating the
> >> row in p_commandeligne_ad creates a new tuple for the row with id of 1.
> >> This means the original statement "delete from commande where id=1" runs
> >> against a version of the row that no longer exists and becomes a no-op
> >> statement. This happens because the trigger was run as BEFORE and
> >> changed the row from under the original statement.
> >
> > Right.
> >
> > regards, tom lane
>
> Thanks for having helped me understand better why it couldn't be a logical
> way of acting.
>
> Best regards,

Actually there is a logic to it once you realize that an UPDATE in Postgres is
really a DELETE and INSERT operation. It is a concept that still catches me
on a regular basis. To see what is going on substitute ctid for oid in your
test case. This will show that the ctid(current tuple id) is changing for the
row you are deleting in commande.

--
Adrian Klaver
aklaver(at)comcast(dot)net

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sebastian Tennant 2008-12-02 16:44:13 Re: Detecting changes to certain fields in 'before update' trigger functions
Previous Message Shane Ambler 2008-12-02 16:16:14 Re: Favorite Tom Lane quotes