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