Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-21 Thread José Orlando Pereira
Jan Wieck wrote: On 1/25/2007 7:33 PM, Tom Lane wrote: 1 fires always 0 fires never N fires in Normal mode R fires in Replica mode other letters available for other future mode values? If you consistently think of

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-03 Thread Jan Wieck
Attached is the implementation of the proposed changes as a patch for discussion. The chosen syntax is backward compatible and uses ALTER TABLE tab ENABLE TRIGGER trig (fires on origin - default) ALTER TABLE tab DISABLE TRIGGER trig (disabled) ALTER TABLE tab ENABLE REPLICA TRIGGER trig (fires

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-03 Thread Joshua D. Drake
Jan Wieck wrote: Attached is the implementation of the proposed changes as a patch for discussion. The chosen syntax is backward compatible and uses ALTER TABLE tab ENABLE TRIGGER trig (fires on origin - default) ALTER TABLE tab DISABLE TRIGGER trig (disabled) ALTER TABLE tab ENABLE

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-02-03 Thread Jan Wieck
On 2/3/2007 5:25 PM, Joshua D. Drake wrote: Jan Wieck wrote: Attached is the implementation of the proposed changes as a patch for discussion. The chosen syntax is backward compatible and uses ALTER TABLE tab ENABLE TRIGGER trig (fires on origin - default) ALTER TABLE tab DISABLE TRIGGER trig

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-29 Thread Jim Nasby
On Jan 26, 2007, at 5:09 PM, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: On 1/26/2007 4:40 PM, Jim Nasby wrote: It would be nice if we had a separate role for replication services so that we weren't exposing superuser so much. So you think about another flag in pg_shadow? Would work

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-27 Thread Markus Schiltknecht
Hi, Jim Nasby wrote: Note that those terms only make sense if you limit yourself to thinking the master is pushing data out to the slave... I don't really get the limitation here. It's all about distinguishing between master/slave, origin/replica, local/remote - however you want to call it.

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Markus Schiltknecht
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

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Chris Browne
[EMAIL PROTECTED] (Markus Schiltknecht) writes: 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

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Jim Nasby
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

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled

2007-01-26 Thread Jim Nasby
On Jan 25, 2007, at 5:33 PM, Jan Wieck wrote: A new per session GUC variable, restricted to superusers, will define if the session is in origin or replica mode. It would be nice if we had a separate role for replication services so that we weren't exposing superuser so much. IIRC Oracle

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Jan Wieck
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

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Jan Wieck
On 1/26/2007 4:40 PM, Jim Nasby wrote: On Jan 25, 2007, at 5:33 PM, Jan Wieck wrote: A new per session GUC variable, restricted to superusers, will define if the session is in origin or replica mode. It would be nice if we had a separate role for replication services so that we weren't

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Jan Wieck
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

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: On 1/26/2007 4:39 PM, Jim Nasby wrote: 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

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: On 1/26/2007 4:40 PM, Jim Nasby wrote: It would be nice if we had a separate role for replication services so that we weren't exposing superuser so much. So you think about another flag in pg_shadow? Would work for me. How exactly would such a role

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-26 Thread Jan Wieck
On 1/26/2007 5:09 PM, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: On 1/26/2007 4:40 PM, Jim Nasby wrote: It would be nice if we had a separate role for replication services so that we weren't exposing superuser so much. So you think about another flag in pg_shadow? Would work for

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled

2007-01-25 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: The value definitions of tg_enabled would be A fires always N fires never O fires on transaction origin only R fires on replica only A new per session GUC variable, restricted to superusers, will define if the session is in

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-25 Thread Jan Wieck
On 1/25/2007 6:55 PM, Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: The value definitions of tg_enabled would be A fires always N fires never O fires on transaction origin only R fires on replica only A new per session GUC variable, restricted to

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding pg_rewrite.ev_enabled

2007-01-25 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: A fires always N fires never O fires on transaction origin only R fires on replica only 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. Hm, N up there seems

Re: [HACKERS] Proposal: Change of pg_trigger.tg_enabled and adding

2007-01-25 Thread Jan Wieck
On 1/25/2007 7:33 PM, Tom Lane wrote: 1 fires always 0 fires never N fires in Normal mode R fires in Replica mode other letters available for other future mode values? If you consistently think of origin and replica modes then the