Re: Why are triggers semi-deferred? - Mailing list pgsql-hackers
| From | Bruce Momjian |
|---|---|
| Subject | Re: Why are triggers semi-deferred? |
| Date | |
| Msg-id | 200306020351.h523pF526257@candle.pha.pa.us Whole thread Raw |
| In response to | Re: Why are triggers semi-deferred? (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
| Responses |
Re: Why are triggers semi-deferred?
|
| List | pgsql-hackers |
I am trying to figure out whether there is a TODO item in this thread.
The basis of the discussion appeared to be whether we are honoring the
spec by executing before/after statement/row/constraint triggers
properly, and if we are not, is it desirable/significant if we break the
spec.
Which need changes?
Before | After
Statement |
Row |
Constraint
Does anyone have answers for these? I read the thread and don't 100%
understand it all.
---------------------------------------------------------------------------
Stephan Szabo wrote:
>
> On Mon, 5 May 2003, Tom Lane wrote:
>
> > Stephan Szabo <sszabo@megazone23.bigpanda.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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
pgsql-hackers by date: