Re: Change the default [tgenabled] for new "internal" triggers ?

Scenario: (not slony, it is home-grown replication)

A change on the Primary db is Captured and then Propagated to the Secondary db.
Then the change is Applied to the Secondary db, with [session_replication_role] = 'replica'.

I agree that I don't want my "user triggers" to fire as part of the Apply.

But my email was about the "internally generated constraint triggers"
which implement checking for Foreign Key Constraint violations.

It is that checking that I want to be done on the Secondary.
Should I not want such checking to be done ?

Thanks,
-dvs-

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, March 23, 2012 8:35 PM
To: Sahagian, David
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Change the default [tgenabled] for new "internal" triggers ?

<david(dot)sahagian(at)emc(dot)com> writes:
> Is the a way to configure Postgres such that tgenabled = ' A' automatically when the FK constraint gets made ?

No. Why do you think that would be a good idea? ISTM it'd lead to the
action being taken twice on the slave.

regards, tom lane