Re: Command Triggers

Hi,

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> An ack about the way it's now implemented would be awesome

I'm still missing that, which is only fair, just a ping from me here.
This is about where to hook in the command trigger calls and which
parameters do we call the procedures with. I've now done it the way Tom
hinted me to, so I guess it's ok.

> Would like a way to say ALL COMMANDS rather than write out list of
> supported commands. That list is presumably subject to change, so not
> having this could result in bugs in later code.

That was included in the patch, but docs were not updated, they are now.

> The example given in the docs has no explanation. More examples and
> explanation please. Would specifically be interested in a command
> trigger which simply prevents all commands, which has many uses and is
> simple enough to be in docs.

Done. Docs still need some more love before commit, I'm planning to be
doing that tomorrow and/or the next days.

> Why do we exclude SEQUENCEs? That could well be a problem for intended users
>
> Please explain/add to docs/comments why ALTER VIEW is not supported?
> Why not other commands??
> Not a problem, but users will ask, so we should write down the answer

I've added support for much more commands (49 of them or something,
including SEQUENCEs), will continue doing so tomorrow, I think we should
be ok to support any and all commands that make sense for 9.2.

I still have some basic CREATE commands to add support for, then CLUSTER
and VACUUM and REINDEX, then it's down to ALTER commands where only
ALTER TABLE is currently finished. That's almost mechanical editing
here, the brain only gets used to pick the right place to hook-in.

The other change I need to make is support for regression tests. I
guess we will want one test per command included. The tests will need
to be in their own file and excluded from the parallel schedule too, or
we would be changing the behavior of the other tests under them and
couldn't compare the outputs anymore.

> Please document why pg_cmdtriggers is a separate table and not
> enhancement of pg_triggers?

Because pg_triggers is made for triggers attached to a relation, as we
can see from that unique constraint:

"pg_trigger_tgrelid_tgname_index" UNIQUE, btree (tgrelid, tgname)

A command trigger is attached to a command rather than a relation, so it
needs to live in its own place:

"pg_cmdtrigger_ctgcommand_ctgname_index" UNIQUE, btree (ctgcommand, ctgname)

I'm not sure how and where to include that in the docs, any advice would
be appreciated.

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