Re: [PATCHES] As proposed the complete changes to pg_trigger and pg_rewrite

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(at)Yahoo(dot)com #

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +