Re: Command Triggers patch v18 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers patch v18
Date
Msg-id 8762dhngmn.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Command Triggers patch v18  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: measuring lwlock-related latency spikes
Next
From: Andrew Dunstan
Date:
Subject: parallel pg_dump