On 3 March 2012 14:34, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote:
> Thom Brown <t...@linux.com> writes:
>> problem. It was the DROP COMMAND TRIGGER statement that garnered
>> comment, as it makes more sense to drop the entire trigger than
>> individual commands for that trigger.
>
> What you're saying here is that a single command could have more than
> one command attached to it, and what I understand Tom, Robert and Kevin
> are saying is that any given command trigger should only be attached to
> a single command.
I hadn't interpreted it that way, but then that could just be my
misinterpretation. I'm still of the opinion that a single command
trigger should be able to attach to multiple commands, just not
amendable once the trigger has been created. If that's not how others
saw it, I'm outnumbered.
So my vote was for:
CREATE COMMAND TRIGGER name { BEFORE | AFTER } command [, ... ]
EXECUTE PROCEDURE function_name ()
ALTER COMMAND TRIGGER name SET enabled
DROP COMMAND TRIGGER [ IF EXISTS ] name [ CASCADE | RESTRICT ]
The only difference shown above compared to the current implementation
in your patch is [, ... ] after command in the CREATE COMMAND TRIGGER
statement.
My argument for this is that you may wish to implement the same
trigger for tables, views and foreign tables rather than create 3
separate triggers.
> If we wanted to be more consistent we would need to have a way to attach
> the same trigger to both BEFORE and AFTER the command, as of now you
> need two triggers here.
I'm not sure I understand. Attaching a trigger to both BEFORE and
AFTER isn't possible for regular triggers so I don't see why that
would introduce consistency. Could you explain?
--
Thom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
