Re: Last gasp

Robert Haas <robertmhaas@gmail.com> writes:
> I am not interested in relitigating on this thread what has already
> been extensively discussed nearby.  Dimitri and I agreed on numerous
> changes to try to make the behavior sane, and those changes were
> suggested and agreed to for good reason.  We didn't agree on every

Those changes are about done now.  I didn't have as much time as I would
have wanted to spend on that this week, so if you want to see my command
trigger patch re-painted into an event trigger system, please go see the
github repository:
 https://github.com/dimitri/postgres/tree/event_triggers
https://github.com/dimitri/postgres/compare/command_triggers...event_triggers
https://github.com/dimitri/postgres/compare/master...event_triggers

dim=# create event trigger snitch before command_start execute procedure snitch();
create event trigger snitch before command_start execute procedure snitch();
CREATE EVENT TRIGGER
dim=# create event trigger another_snitch before command_start when tag in (create table, create view) execute
proceduresnitch();
 
create event trigger another_snitch before command_start when tag in (create table, create view) execute procedure
snitch();
CREATE EVENT TRIGGER

> point, of course, but we did agree on most of it, and there is no
> patch that implements what was agreed.  Even if there were, there is
> not time to review and commit a heavily revised version of a >1000
> line patch before tomorrow, and any suggestion to the contrary is just
> plain wrong.

The main problems were, as you say it in another mail, the hook
placement and the ddl-in-ddl.

The hook placement is being solved thanks to naming several "events"
where the trigger are fired. We could have done that in a much simpler
way by deciding on when a BEFORE trigger really ought to be called,
instead of doing that we're generalizing the system so that you can
register your user function before events such as "command_start", or
"create_command" or "security_check". Coming next, calling user
functions *instead of* those steps (not done in the 9.2 version).

The ideas about toplevel commands and calling user functions on CASCADEd
objects drops is now possible to implement but not yet in the patch,
it's simple enough to do.

Calling DDL from a DDL trigger in a way that could change the conditions
in which the main command is expecting to run (drop the object being
altered in the trigger) is certainly a "shoot yourself in the foot" case
and the feature is superuser only: we're talking about a doc patch here.

My conclusion here is very simple: if we *want* that feature, we can
easily enough have it in 9.2 in some form. That will include the
possibility to code a C-extension to implementing command rewriting for
use in our 3 major trigger based replication systems, and custom
applications too.

It's been about a year since we started talking about that topic, and it
only changed from being "command triggers" to being "event triggers"
last week during review, at version 18 of the patch, each previous
version having been both public and reviewed and tested.

So, as a community, do we want the feature and are we able to cook
something up for 9.2?

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support