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

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