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

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?


Jan


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