On Sun, Apr 1, 2012 at 7:22 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> See above example: I am pretty sure you need a stack.
>
> In next version, certainly. As of now I'm willing to start a new stack
> in each command executed in a command trigger. That means 9.2 will only
> expose the first level of the stack, I guess.
I think we're talking past each other. If someone executes DDL
command A and the command trigger executes DDL command B which fires
another command trigger, then the command trigger for A needs to see
the information relevant to A both before and after the command
trigger for B executes. So you can't just store all the context
information in a flat global variable, because otherwise when the
trigger for B executes it will clobber the values for A. You need to
do a save/restore so that when the execution of the trigger on A
resumes, it still sees the right stuff.
> Well it depends on what you're achieving with replication, this term
> includes so many different use cases… What I want core to provide is the
> mechanism that allows implementing the replication you need.
Agreed.
>> See above - generally, I think that it's useful for a command trigger
>> to know that it's being called because of a DDL event, rather than
>> some command that could be doing anything. Also, I think that wanting
>> to hook "all DDL commands" is likely to be a useful thing to do, and
>> without having to explicitly list 50 command names...
>
> Yeah, just omit the WHEN clause then.
Well, that's "absolutely everything" rather than just "all DDL".
What's the use case for that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
