On 3 March 2012 19:25, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.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
