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>;
> 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  <[EMAIL PROTECTED]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to