Re: [PATCHES] As proposed the complete changes to pg_trigger and pg_rewrite - Mailing list pgsql-hackers

Jan Wieck wrote:
> On 3/21/2007 10:24 PM, Bruce Momjian wrote:
> > Ah, so you wait for me to go on vacation to apply it!  Well, I am back
> > now, buddy.  ;-)
> 
> Got to use my chances, don't I? :-p
> 
> > 
> > One thing that bothers me about the patch is that it seems you are
> > adding functionality that allows you to enable/disable trigger firing in
> > groups, which is fine, but you are hard-coding the use of that grouping
> > to be replication, e.g. "origin", "replica", etc.
> > 
> > Should these designations be more generic in case there are other uses
> > for enabling/disabling groups of triggers?
> 
> That would be fine with me, I just wasn't able to come up with any 
> sensible naming scheme other than replication related. Can you?

The best I could think of would be to create numbered groups of
triggers, but because I can't think of any use for that, and no one else
has, I think the patch is fine unchanged.

---------------------------------------------------------------------------

> > Jan Wieck wrote:
> >> For discussion:
> >> 
> >> Attached is the completed patch that changes pg_trigger and extends
> >> pg_rewrite in order to allow triggers and rules to be defined with
> >> different, per session controllable, behaviors for replication purposes.
> >> 
> >> This will allow replication systems like Slony-I and, as has been stated
> >> on pgsql-hackers, other products to control the firing mechanism of
> >> triggers and rewrite rules without modifying the system catalog directly.
> >> 
> >> The firing mechanisms are controlled by a new superuser-only GUC
> >> variable, session_replication_role, together with a change to
> >> pg_trigger.tgenabled and a new column pg_rewrite.ev_enabled. Both
> >> columns are a single char data type now (tgenabled was a bool before).
> >> The possible values in these attributes are:
> >> 
> >>       'O' - Trigger/Rule fires when session_replication_role is "origin"
> >>             (default) or "local". This is the default behavior.
> >> 
> >>       'D' - Trigger/Rule is disabled and fires never
> >> 
> >>       'A' - Trigger/Rule fires always regardless of the setting of
> >>             session_replication_role
> >> 
> >>       'R' - Trigger/Rule fires when session_replication_role is "replica"
> >> 
> >> The GUC variable can only be changed as long as the system does not have
> >> any saved SPI plans. This will prevent changing the session role and
> >> accidentally executing stored procedures or functions that have plans
> >> cached that expand to the wrong query set due to differences in the rule
> >> firing semantics.
> >> 
> >> The SQL syntax for changing a triggers/rules firing semantics is
> >> 
> >>       ALTER TABLE <tabname> <when> TRIGGER|RULE <name>;
> >> 
> >>       <when> ::= ENABLE | ENABLE ALWAYS | ENABLE REPLICA | DISABLE
> >> 
> >> psql's \d command as well as pg_dump are extended in a backward
> >> compatible fashion.
> >> 
> >> Any volunteers to do the corresponding documentation changes should this
> >> patch be accepted?
> >> 
> > 
> 
> 
> -- 
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me.                                  #
> #================================================== JanWieck@Yahoo.com #

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +