Re: Using results from INSERT ... RETURNING

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> While we're discussing explain output ... what about triggers?
>> An important aspect of this change is that at least the row-level
>> triggers are now going to be charged as runtime of the
>> Dml-or-whatever-we-call-it node. Should we rearrange the explain
>> output so that the printout for trigger runtimes is associated
>> with those nodes too? If so, what about statement-level triggers?

> That's not a bad idea, though it wouldn't bother me much if we left it
> for a follow-on patch.

After cogitating on this for a few minutes, it seems to me that the
right thing to do is to push the calling of statement-level triggers
into the Dml node too. That is, ExecDml() would be responsible for
calling BEFORE STATEMENT triggers at the start of its first call,
and for calling AFTER STATEMENT triggers at the end of its last
call (just before it returns NULL). This would mean that all trigger
activity is now associated with a plan node and should be reported
that way by EXPLAIN. We could get rid of the rather warty top-level
XML item for triggers and make the trigger instrumentation outputs
just be another plan node property.

Aside from having a cleaner EXPLAIN output design, this would mean that
triggers in the planned WITH RETURNING scenario fire in the order you'd
expect if we are considering the WITH RETURNING queries to be done
sequentially and before the main query. From a user's standpoint it
would look just like you'd issued the queries sequentially, except that
the RETURNING data is held for use in the main query.

regards, tom lane