Re: Event Triggers: adding information

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 17, 2013 at 4:43 PM, Dimitri Fontaine
> <dimitri@2ndquadrant.fr> wrote:
>> because that
>> sounded logical if you believe in CommandCounterIncrement.

> I'm somewhat bemused by this comment.  I don't think
> CommandCounterIncrement() is an article of faith.  If you execute a
> command to completion, and do a CommandCounterIncrement(), then
> whatever you do next will look just like a new command, so it should
> be safe to run user-provided code there.  But if you stop in the
> middle of a command, do a CommandCounterIncrement(), run some
> user-provided code, and then continue on, the
> CommandCounterIncrement() by itself protects you from nothing. If the
> code is not expecting arbitrary operations to be executed at that
> point, and you execute them, you get to keep both pieces.  Indeed,
> there are some places in the code where inserting a
> CommandCounterIncrement() *by itself* could be unsafe.

I think it's quite likely that we should *not* expect that we can safely
do CommandCounterIncrement at any random place.  That isn't just "x++".
It causes relcache and catcache flushes for anything affected by the
command-so-far, since it's making the command's results visible --- and
the code may not be expecting the results to become visible yet, and
almost certainly isn't expecting cache entries to disappear under it.
So a CCI could break things whether or not the event trigger itself did
anything at all.

But this is just one part of the general problem that injecting random
code mid-command is risky as hell, and isn't likely to become less so.
Frankly I don't really wish to see that happen, and don't immediately
see good end-user reasons (as opposed to structure-of-the-current-code
reasons) to need it.  I'd really like to get to a point where we can
define things as happening like this:
* collect information needed to interpret the DDL command  (lookup and lock objects, etc)* fire "before" event
triggers,if any (and if so, recheck info)* do the command* fire "after" event triggers, if any
 

This might require that the command execution save aside information
that would help us fire appropriate event triggers later.  But I'd much
rather pay that overhead than fire triggers mid-command just because
that's where the info is currently available.

BTW, how badly do we need the "before" case at all?  If we were to
restrict our ambitions to "after" triggers, it would perhaps be
relatively simple for DDL execution to create data structures noting
what it does as it goes along, and then use those to fire "after"
triggers at the end (and provide desired info to them too).  Still
a lot of new code of course, but not very much risk involved.

[ reads further... ]  Robert seems to have pretty much that same idea
down at the end:

> One idea would be to save off all the names of the objects actually
> dropped at the time the drops are done, and then pass it to the event
> trigger afterward.
        regards, tom lane