From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Jim Nasby <decibel(at)decibel(dot)org> |
Cc: | Markus Schiltknecht <markus(at)bluegap(dot)ch>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Change of pg_trigger.tg_enabled and adding |
Date: | 2007-01-26 21:47:13 |
Message-ID: | 45BA76E1.8010908@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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".
>
> Also, if enums will be in 8.3, perhaps they can be used instead of
> "char"?
I don't like this one. It makes it impossible to provide patches,
enabling this replication system on older Postgres releases. And you
know that your customers will want them.
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 #
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2007-01-26 21:48:47 | Re: Proposal: Change of pg_trigger.tg_enabled and adding |
Previous Message | Heikki Linnakangas | 2007-01-26 21:46:28 | Re: PostgreSQL Data Loss |