Re: Command Triggers, patch v11

On 3 March 2012 19:25, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Right.  What I thought I was agreeing with was the notion that you
>> should need to specify more than the trigger name to drop the
>> trigger.  Rather like how you can create a trigger AFTER INSERT OR
>> UPDATE OR DELETE, but you don't need to specify all those events to
>> drop the trigger -- just the name will do.
>
> The parallel between INSERT/UPDATE/DELETE and the trigger's command is
> not working well enough, because in the data trigger case we're managing
> a single catalog entry with a single command, and in the command trigger
> case, in my model at least, we would be managing several catalog entries
> per command.
>
> To take an example:
>
>  CREATE COMMAND TRIGGER foo AFTER create table, create view;
>  DROP COMMAND TRIGGER foo;
>
> The first command would create two catalog entries, and the second one
> would delete the same two entries.  It used to work this way in the
> patch, then when merging with the new remove object infrastructure I
> lost that ability.  From the beginning Robert has been saying he didn't
> want that behavior, and Tom is now saying the same, IIUC.
>
> So we're back to one command, one catalog entry.

That sucks. I'm surprised there's no provision for overriding it on a
command-by-command basis.

I would suggest an array instead, but that sounds costly from a
look-up perspective.

--
Thom