From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why are triggers semi-deferred? |
Date: | 2003-05-05 17:58:42 |
Message-ID: | 20030505103925.F87200-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 5 May 2003, Tom Lane wrote:
> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > Actually, I think from sql99's description, for after row triggers it
> > should happen after the row is modified not after the statement as a
> > whole (so given two 2 row updates in a function you'd get
> > update1,row1 afterrow1-1 update1,row2 afterrow1-2,afterstatement1
> > update2,row1 afterrow2-1 update2,row2 afterrow2-2,afterstatement2
> > )
>
> [ scratches head ... ] That seems a useless definition. What is the
> purpose of firing immediately after, rather than immediately before,
> a row update? Wouldn't you want to wait till end of statement so you
> know that the whole statement is in fact going to complete (and not
> die at some later row)? What do you have immediately after the update
> that you didn't have just before it?
You're right, I'd misread "the trigger event" as being a row change for a
row trigger (go figure). However, looking at it, then I'm not sure our
before row trigger timing is correct then. It seems from 14.14 for a
delete example that the timing is supposed to be something like:
before trigger 1
before trigger 2
delete 1
delete 2
after trigger 1
after trigger 2
rather than:
before trigger 1
delete 1
before trigger 2
delete 2
after trigger 1
after trigger 2
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-05-05 19:19:58 | Hypothetical suggestions for planner, indexing improvement |
Previous Message | Tom Lane | 2003-05-05 16:58:04 | Re: Why are triggers semi-deferred? |