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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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