Re: Command Triggers

Andres Freund <andres(at)anarazel(dot)de> writes:
>> create trigger foo after command CREATE TABLE …
>> create trigger foo after top level command CREATE TABLE …
>> create trigger foo after nested command CREATE TABLE …
>>
>> Either we add support for that kind of syntax now (and not implementing
>> it in 9.3 would seem weird as hell) or we instruct pg_dump and
>> pg_upgrade to switch from current syntax to the new one (add in the “top
>> level” keywords) when we do implement the feature down the road.
> I personally think there should only be one variant which is always called.
> With a parameter that indicates whether its a subcommand or not.
>
> Why would you ever only want top level commands?

Because the command "create table foo(id primary key)" could then fire
your "index" and "constraint" command triggers twice and if all you do
is storing the command string in a table for auditing purposes, maybe
you just don't care.

>> Yes, we need to make a decision about that now. Do we want any
>> “operation” to go through ProcessUtility so that hooks and command
>> triggers can get called?
> I personally think thats a good idea for most stuff.
>
> I don't see that for alter table subcommands and such though.

By subcommand, I mean any operation that a main command do for you and
that you could have been doing manually with another command, such as
serial and sequences, primary key and its alter table form, embedded
checks or not null and its alter table form, etc.

I don't remember that ALTER TABLE implement facilities that are in turn
calling another command for you?

>> I think it's a good idea in the long run, and Alvaro seems to be
>> thinking it is too. That entails changing the backend code to build a
>> Statement then call ProcessUtility on it rather than calling the
>> internal functions directly, and that also means some more DDL are
>> subject to being logged on the server logs. Removing those
>> “cross-modules” #include might be a good think in the long run though.
> Uhm. I don't think building strings is the way to go here. I think building
> *Stmt nodes is better.

Agreed, I meant that exactly.

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