On Sun, Apr 1, 2012 at 7:22 AM, Dimitri Fontaine <dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
