Peter Eisentraut <peter_e@gmx.net> writes:
> Random observation in this general area: Regular triggers provide the
> field Trigger *tg_trigger in the trigger data, which allows you to get
> the trigger name, OID, and such. Event triggers don't expose anything
> comparable. That should perhaps be added.
Agreed.
Basically we ran out of time to add in any sort of useful information,
so that's all 9.4 material.
> Also, as I'm maybe about the fourth person ever to write an actual event
> trigger, I have a usability report of sorts. I found it confusing that
> the trigger timing is encoded into the event name. So instead of ON
> ddl_command_start, I was expecting something more like BEFORE
> ddl_command. There might be a reason for this design choice, but I
> found it a confusing departure from known trigger concepts.
Your proposal here matches what I did propose in the 9.2 cycle. I even
wanted to go as far as having BEFORE, AFTER and INSTEAD OF command
triggers.
The problem was to find the right place in the code for each different
command, and while I did work on that and proposed command specific
integration points, Robert had the idea of having something more
flexible and not tied too much with commands, hence events.
The idea is to be able to provide events such as "table_rewrite" or
"insert_into_unknown_table" etc.
How we got from that decision to prefer "ddl_command_start" to BEFORE
"ddl_command" still is unclear to me. We could have kept the grammar and
turned it internally into the "before_ddl_command" event.
But then certainly you want to be able to say BEFORE CREATE TABLE, ALTER
TABLE or BEFORE ANY EVENT, things like that. In the patches I sent
containing that kind of implementation, it was said to be too much
grammar to maintain, as the patch I had needed to list here all
supported commands, and each time to add support for a new one you
needed to edit that grammar list…
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
