Possible patch to remove "triggered data change" support

Attached is a patch to remove the "triggered data change" error check
from trigger.c, as well as pick up the performance improvements that
that allows (due to not having to save deferred trigger events as long).

I am not yet proposing to actually commit this, since the discussion
about whether it's a good idea is still ongoing in -hackers. But
Stephan seemed to want to have a copy for testing purposes, and I
thought other people might be interested too.

Are you saying we never need to save deferred trigger events any longer,
or just in this case?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Are you saying we never need to save deferred trigger events any longer,
or just in this case?

The only reason we save 'em beyond the time they are executed is to support
"triggered data change" detection.

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Are you saying we never need to save deferred trigger events any longer,
or just in this case?

The only reason we save 'em beyond the time they are executed is to support
"triggered data change" detection.

I assume we still need a queue for deferred triggers, right? We just
now don't need to keep them after that like we used to, right?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I assume we still need a queue for deferred triggers, right?

There's still a queue. But it saves fewer events for shorter intervals
than it used to. Example: in the present code, if you have *any*
deferred triggers (for INSERT, UPDATE, or DELETE) on a rel then queue
entries are made for *all* triggerable events (INSERT, UPDATE, or
DELETE) on that rel. In the proposed patch, if you have only an AFTER
INSERT trigger then no queue entries are made for UPDATE or DELETE
events, etc. This has a direct bearing on the number of queue entries
made in RI scenarios, since the RI triggers are for subsets of events.

regards, tom lane