Skip site navigation (1) Skip section navigation (2)

Re: Command Triggers

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Command Triggers
Date: 2011-12-01 21:02:18
Message-ID: CA+U5nM+8KSKx+VfdRGj3qmDSBaxRzir4RnzTqOFuQo6-3KBHqQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Nov 26, 2011 at 7:20 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:

> FWIW (scheduling mainly), I don't think I'm going to spend more time on
> this work until I get some comments, because all that remains to be done
> is about building on top of what I've already been doing here.

+1 overall


One of the main use cases for me is the ability to
* prevent all commands
* prevent extension commands - to maintain stable execution environment

Those are especially important because in 9.2 DDL commands will cause
additional locking overheads, so preventing DDL will be essential to
keeping performance stable in high txn rate databases.

So I'd like to see a few more triggers that work out of the box for
those cases (perhaps wrapped by a function?). It would also allow a
more useful man page example of how to use this.


On the patch, header comment for cmdtrigger.c needs updating.
Comments for DropCmdTrigger etc look like you forgot to update them
after cut and paste.

Comments say "For any given command tag, you can have either Before
and After triggers, or
 Instead Of triggers, not both.", which seems like a great thing to
put in the docs.

Looks good.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-12-01 21:08:29
Subject: Re: Postgresql 9.1 replication failing
Previous:From: Andres FreundDate: 2011-12-01 20:57:40
Subject: Re: Command Triggers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group