Thread

Sync BEFORE STATEMENT trigger behavior with AFTER STATEMENT

Tom Lane <tgl@sss.pgh.pa.us> — 2017-09-16T18:03:12Z

The just-committed patch 0f79440fb arranges to suppress extra firings
of AFTER STATEMENT triggers that historically have occurred when
several FK enforcement trigger firings affect the same target table.
This leaves us in a situation where you may get more BEFORE STATEMENT
trigger firings than AFTER STATEMENT firings, which seems weird.

I did the attached simple patch to change this, using state very
similar to that now used for AFTER STATEMENT triggers.  It works, in
terms of syncing the number of trigger calls.  The timing of the
calls might seem a bit weird, as shown in the modified regression
test case.  In the corner cases where you can get multiple statement
trigger firings out of one original SQL statement, the ordering
tends to look like
	BEFORE STATEMENT
	BEFORE STATEMENT
	AFTER STATEMENT
	AFTER STATEMENT
not what you might expect,
	BEFORE STATEMENT
	AFTER STATEMENT
	BEFORE STATEMENT
	AFTER STATEMENT
I'm not sure there's anything we can or should do about that, though.
Certainly we don't want to delay the execution of BEFORE calls.

I think we should push this into v10 so that we maintain consistency
of BEFORE vs. AFTER STATEMENT behavior.  Objections?

			regards, tom lane