Re: Making AFTER triggers act properly in PL functions
От | Tom Lane |
---|---|
Тема | Re: Making AFTER triggers act properly in PL functions |
Дата | |
Msg-id | 25050.1094685424@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Making AFTER triggers act properly in PL functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Making AFTER triggers act properly in PL functions
|
Список | pgsql-hackers |
Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > On Wed, 8 Sep 2004, Tom Lane wrote: >> As long as we're talking about hack-slash-and-burn on this data >> structure ... > Where the OtherInformation could be shared within the statement (for > identical events)? I think it'd be problematic to try sharing between > statements. Yeah, I had come to the same conclusion after more thought. But we could certainly aggregate all the similar events generated by a single query into a common status structure. > But, I'm sort of assuming the following are true: > Once a group of items is marked to be run, all items will run even if set > constraints ... deferred happens while the run occurs. That's a good question. If the first trigger firing tries to set the event deferred, what happens to the remaining triggers? The SQL spec doesn't even touch this question, so I think we are at liberty to do what we like. I don't see that it's unreasonable to continue to fire events that were marked as firable when we reached the end of the current statement. > If an error occurs, either the entire set of event objects for the > statement are going away because they're new, or if it was something run > from set constraints we're going to want to rerun the entire set anyway. Right, that was what I was thinking. regards, tom lane
В списке pgsql-hackers по дате отправления: