Re: Proposal: Change of pg_trigger.tg_enabled and adding

Hi,

Nice proposal. I'd support that enhancement and could make use of such 
triggers in Postgres-R as well, at least to provide these triggers to 
the user.

Jan Wieck wrote:
> Good question. I don't know. I'd rather error on the safe side and make 
> it multiple states, for now I only have Normal and Replica mode.

Are these triggers intended to help implement async replication or are 
these for users to be able to take action on remote replay of a 
transaction (i.e. on the replica)? Does that give a further distinction?

In Postgres-R, I mostly use the terms 'local' and 'remote'. Also, 
"normal mode" can easily be confused with "non-replicated" mode, thus 
I'd not mix that with replicated, local transaction mode (even if it's 
mostly equal, as in this case). My naming proposal would thus be:
    A   fires always (i.e. fires N times, where N = nr of nodes)    L   fires on the transaction local node (i.e. only
exactlyonce)    R   fires on the remote nodes only (i.e. (N - 1) times)    0   fires never
 

'1' for "fires on both nodes" seems confusing as well, because it's not 
like in single node DB operation, in that one event can fire the trigger 
multiple times (on different nodes). The current, single node PostgreSQL 
should thus use '0' or 'L'.

Regards

Markus