On Sat, Mar 3, 2012 at 2:25 PM, 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.
I hadn't made the connection here until you read this, but I agree
there's a problem there. One command, one catalog entry is, I think,
pretty important. So that means that if want to support a trigger on
CREATE TABLE OR CREATE VIEW OR DROP EXTENSION, then the command names
(or integers that serve as proxies for them) need to go into an array
somewhere, and we had to look for arrays that contain the command
we're looking for, rather than just the command name. That might seem
prohibitively slow, but I bet if you put a proper cache in place it
isn't, because pg_cmdtrigger should be pretty small and not updated
very often. You can probably afford to seq-scan it and rebuild your
entire cache across all command types every time it changes in any
way.
But just supporting one command type per trigger seems fine for a
first version, too. There's nothing to prevent us from adding that
later.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
