Re: WIP: push AFTER-trigger execution into ModifyTable node

Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
> <marko.tiikkaja@cs.helsinki.fi> wrote:
>> What I've had in mind is pipelining the execution only when it doesn't
>> have *any* impact on the outcome. �This would mean only allowing it when
>> the top-level statement is either a SELECT or an INSERT. �Also, UPDATEs
>> and DELETEs inside CTEs can't have the same result relations. �Whether
>> or not we want to break the expected(?) behaviour for statement-level
>> triggers, I have no opinion to way or another.

> You'd also have to disallow the case when there are any triggers on
> the INSERT, or where there are any triggers on anything else (because
> they might access the target table of the INSERT).  This will end up
> being so restricted as to be useless.

Well, it's already the case that BEFORE triggers shouldn't count on
seeing any particular subset of a statement's results completed.
We could define AFTER triggers as all being fired after the entire
statement is complete (which is not the direction my patch was headed
in, but I have no allegiance to that).  So I think we could define our
way out of the trigger timing issue, and I don't see any big objection
to limiting pipelining to cases where the sub-statements' target tables
don't overlap.

However, this still doesn't address the problem of what happens when the
top-level select fails to read all of the CTE output (because it has a
LIMIT, or the client doesn't read all the output of a portal, etc etc).
Partially executing an update in such cases is no good.
        regards, tom lane