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

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

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