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

From Bruce Momjian
Subject Re: [PATCHES] As proposed the complete changes to pg_trigger and pg_rewrite
Date
Msg-id 200703220224.l2M2Ocr11146@momjian.us
Whole thread Raw
Responses Re: [PATCHES] As proposed the complete changes to pg_trigger and pg_rewrite  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Ah, so you wait for me to go on vacation to apply it!  Well, I am back
now, buddy.  ;-)

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?

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

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?
> 

--  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. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: fixing dllist?
Next
From: Tatsuo Ishii
Date:
Subject: Proposal: Adding JIS X 0213 support