From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
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 16:07:48 |
Message-ID: | 28194.1052150868@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-05-05 16:09:29 | Re: Why are triggers semi-deferred? |
Previous Message | Stephan Szabo | 2003-05-05 16:07:18 | Re: Why are triggers semi-deferred? |