Re: Why are triggers semi-deferred?

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why are triggers semi-deferred?
Date: 2003-07-12 14:48:41
Message-ID: 5.1.0.14.0.20030713003704.036c4cf0@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 11:51 PM 1/06/2003 -0400, Bruce Momjian wrote:
>Does anyone have answers for these? I read the thread and don't 100%
>understand it all.

My belief is that at least ROW triggers need fixing (7.3 doesn't have
statement, not sure about 7.4).

Currently, if you write a plpgsql procedure which calls more than one
insert/update/delete statements, the AFTER triggers for all of these
statements will not fire until after the procedure exits. They should fire
either just after each row is updated, or just after the most immediately
enclosing statement executes. I think the thread wanted the latter.

So, if we have a table with two rows, and a BEFORE and AFTER trigger, and a
plpgsql procedure that updates all rows twice, then we should have:

procedure called
procedure executes first update
before trigger fires(row 1)
before trigger fires(row 2)
row 1 updated
row 2 updated
after trigger fires(row 1)
after trigger fires(row 2)
procedure executes second update
before trigger fires(row 1)
before trigger fires(row 2)
row 1 updated
row 2 updated
after trigger fires(row 1)
after trigger fires(row 2)
procedure exits

What we have in 7.3 is:

procedure called
procedure executes first update
before trigger fires(row 1)
before trigger fires(row 2)
row 1 updated
row 2 updated
procedure executes second update
before trigger fires(row 1)
before trigger fires(row 2)
row 1 updated
row 2 updated
procedure exits
after trigger fires(row 1)
after trigger fires(row 2)
after trigger fires(row 1)
after trigger fires(row 2)

IIRC, the thread did not really discuss whether do intersperse the BEFORE
executions with the updates, but doing them all before seems consistent.

Apologies is this has been covered elsewhere...

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ivan 2003-07-12 17:45:12 new src :>
Previous Message Bruno Wolff III 2003-07-12 13:42:52 Re: agg/order-by question