Re: Proposal: Change of pg_trigger.tg_enabled and adding

On 1/26/2007 4:47 PM, Jan Wieck wrote:
> On 1/26/2007 4:39 PM, Jim Nasby wrote:
>> On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
>>> In Postgres-R, I mostly use the terms 'local' and 'remote'.
>>
>> Note that those terms only make sense if you limit yourself to
>> thinking the master is pushing data out to the slave...
>>
>> I think it'd make the most sense if the name reflected whether the
>> trigger should be fired by a replication process or not; that way it
>> doesn't really matter if it's a master or a slave... if the data in
>> the table is being modified by a replication process then you don't
>> fire the trigger/rule, according to the setting. But maybe there is
>> some need to discern between origin and target...
>
> That's why I prefer "origin" and "replica". I want to use the same terms
> in the sessions mode GUC, and there "local" could be misinterpreted as
> "doesn't replicate at all".

I will need that "local" mode anyway for some conflict resolutions.
Think of a duplicate key (yeah, yeah, what comes now sounds bad ...)
conflict, where you need to delete one of the entries without causing
that delete to replicate.

Before people panic, the final system is supposed to have something
smarter than deleting a dupkey in its repertoire. But I'll rather go
with this cheap shot first and add a group communication based advisory
locking system later, you know?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #