Re: Proposal: Change of pg_trigger.tg_enabled and adding
От | Jan Wieck |
---|---|
Тема | Re: Proposal: Change of pg_trigger.tg_enabled and adding |
Дата | |
Msg-id | 45BA76E1.8010908@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Proposal: Change of pg_trigger.tg_enabled and adding (Jim Nasby <decibel@decibel.org>) |
Ответы |
Re: Proposal: Change of pg_trigger.tg_enabled and adding
Re: Proposal: Change of pg_trigger.tg_enabled and adding |
Список | 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@Yahoo.com #
В списке pgsql-hackers по дате отправления: