Re: Command Triggers - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
>> Wait, we already have ALTER TRIGGER bob ON ANY COMMAND SET DISABLED;
>
> Eh, so what happens then if someone sets a command trigger on ALTER TRIGGER?

We should remove support for command triggers on alter command triggers.
Well I could also go with the GUC idea, it's only that I'm not entirely
sold it's the best we can do yet and I'd like to avoid yet another GUC.

>> Why would we do it that way (a single entry for multiple commands)?  The
>> way it is now, it's only syntactic sugar, so I think it's easier to
>> implement, document and use.
>
> Well, for one thing, it's consistent with how we handle it for regular
> triggers. For two things, if you create an object named bob, you

I don't think so, if you attach the same procedure to more than one
table each time with the same name, you get multiple entries in
pg_trigger:
   "pg_trigger_tgrelid_tgname_index" UNIQUE, btree (tgrelid, tgname)

create trigger footg after insert on tg.foo for each row execute procedure tg.trigfunc();
create trigger footg after insert on tg.bar for each row execute procedure tg.trigfunc();
create trigger footg after insert on tg.baz for each row execute procedure tg.trigfunc();

select oid, tgrelid::regclass, tgname, tgfoid, tgtype, tgenabled from pg_trigger; oid   | tgrelid | tgname | tgfoid |
tgtype| tgenabled  
--------+---------+--------+--------+--------+-----------533210 | tg.foo  | footg  | 533209 |      5 | O533211 | tg.bar
| footg  | 533209 |      5 | O533212 | tg.baz  | footg  | 533209 |      5 | O 
(3 rows)

The difference I see is that in the table trigger case you don't have a
syntax that allows you to do the 3 operations I did above in 1 command,
and it's easy to provide for this capability with command triggers (and
the use case is much bigger too, as all command triggers are given the
same arguments and all expected to return void).

> expect to end up with an object named bob - not 47 objects (or
> whatever) that are all named bob.  Also, suppose you create a trigger
> on ALL COMMANDS, and then a new version of PG adds a new command.

You create a trigger on ANY command :)

> When you dump and reload, do you expect to end up with a trigger on
> all commands that existed in the old version, or all the commands that
> exist in the new version?  Or conversely, suppose we get rid of a
> command in a future release.  How will we handle that?  I can't think
> of another example of where a CREATE command creates multiple objects
> like that.

ANY COMMAND triggers are just one entry in pg_cmdtrigger, with the
command name registered as "ANY", which is only safe as long as we don't
provide a new SQL command whose command tag is ANY. We could decide that
we want to name this magic ANY command "__ANY__", but it does not look
like it fits the project usual naming style.

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