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?  (Philip Warner <pjw@rhyme.com.au>)
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:

Previous
From: Bruce Momjian
Date:
Subject: Re: compile error on cvs tip
Next
From: Tom Lane
Date:
Subject: Re: pg_database encoding again