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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Oct 31, 2009 at 5:00 PM, Marko Tiikkaja
> <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)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