From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Command Triggers patch v18 |
Date: | 2012-04-03 12:29:04 |
Message-ID: | 8762dhngmn.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.
Agreed. I was trying to say that we won't have all of this in 9.2.
>> Yeah, just omit the WHEN clause then.
>
> Well, that's "absolutely everything" rather than just "all DDL".
> What's the use case for that?
You can still filter in the trigger code. A use case is forbidding any
command that's not purely data related to happen in certain cases, like
live server migrations.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-04-03 13:26:52 | parallel pg_dump |
Previous Message | Kevin Grittner | 2012-04-03 12:28:26 | Re: measuring lwlock-related latency spikes |