Command Triggers, patch v11 - Mailing list pgsql-hackers
From | Dimitri Fontaine |
---|---|
Subject | Command Triggers, patch v11 |
Date | |
Msg-id | m24nufq466.fsf@2ndQuadrant.fr Whole thread Raw |
Responses |
Re: Command Triggers, patch v11
Re: Command Triggers, patch v11 |
List | pgsql-hackers |
Hi, Please find attached the latest version of the command triggers patch, in context diff format, with support for 79 commands and documentation about why only those, and with some limitations explained. I also cleaned up the node function support business that was still in there from the command rewriting stuff that we dropped, and did a merge from tonight's master branch (one of a few clean merges). This is now the whole of it, and I continue being available to make any necessary change, although I expect only minor changes now. Thanks to all reviewers and participants into the previous threads, you all have allowed me to reach the current point by your precious advice, comments and interest. The patch implements : - BEFORE/AFTER ANY command triggers - BEFORE/AFTER command triggers for 79 documented commands - regression tests exercised by the serial schedule only - documentation updates with examples That means you need to `make installcheck` here. Installing the tests in the parallel schedule does not lead to consistent output as installing a command trigger will impact any other test using that command, and the output becomes subject to the exact ordering of the concurrent tests. The only way for a BEFORE command triggers to change the command's behaviour is by raising an exception that aborts the whole transaction. Command triggers are called with the following arguments: - the “event” (similar to TG_WHEN, either 'BEFORE' or 'AFTER') - the command tag (the real one even when an ANY trigger is called) - the object Id if available (e.g. NULL for a CREATE statement) - the schema name (can be NULL) - the object name (can be NULL) When the trigger's procedure we're calling is written in C, then another argument is passed next, which is the parse tree Node * pointer. I've been talking with Marko Kreen about supporting ALTER TABLE and such commands automatically in Londiste: given that patch, it requires writing code in C that will rewrite the command string. It so happens that I already have worked on that code, so we intend on bringing support for ALTER TABLE and other commands in Skytools 3 for 9.2. I think the support code should be made into an extension that both Skytools and Slony would be able to share. The extension code will be able to adapt to major versions changes as they are released. Bucardo would certainly be interested too, we could NOTIFY it from such an extension. The design is yet to be done here, but it's clearly possible to implement such a feature given the current patch. The ANY trigger support is mainly there to allow people to stop any DDL traffic on their databases, then allowing it explicitly with an ALTER COMMAND TRIGGER ... SET DISABLE when appropriate only. To that end, the ANY command trigger is supporting more commands than you can attach specific triggers too. It's also possible to ENABLE a command trigger on the REPLICA only thanks to the session_replication_role GUC. Support for command triggers on an Hot Standby node is not provided in this patch. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachment
pgsql-hackers by date: