Re: Making AFTER triggers act properly in PL functions

On Wed, 8 Sep 2004, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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.

Definately. The ~20 byte/row gain for large updates/insert/delete is
worth it. I think it'd actually increase the size for the single row case
since we'd have the pointer to deal with (we could use a flag that tells
us whether this item actually has a pointer to a shared status structure
or just contains the status structure but that seems kinda ugly).

> > 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.

That's what I figured, especially if a function called in an update that
does a set constraints doesn't act upon the triggers being queued
effectively until the end of statement.