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 even uses  
2 roles; one for administration of replication and one that the  
replication code actually runs under.

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


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

2007-01-25 Thread Jan Wieck

The experience with Slony-I has shown that

  a) different behavior of triggers and rules on a transactions origin
 and a replica is essential;

  b) mucking around with the system catalog to achieve this is futile.

This would be even more catastrophic in a multimaster environment, where 
regular transaction origin and replica behavior are required on a per 
session level concurrently.


To achieve the required flexibility, we need to change the definition of 
the pg_trigger attribute tg_enabled. It currently is a boolean. I would 
like to change it into a char along with the syntax of ALTER TRIGGER. 
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

Anyone preferences how to map that to ALTER TRIGGER?

A new per session GUC variable, restricted to superusers, will define if 
the session is in origin or replica mode.


Likewise the system catalog pg_rewrite is extended with an attribute 
ev_enabled. It will have the same possible values and a new command, 
ALTER RULE, will match the functionality of ALTER TRIGGER.



Jan

--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


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 origin or replica mode.

Are you sure two states are enough?

No particular objection, but now would be the time to think if a boolean
is sufficient.

 Likewise the system catalog pg_rewrite is extended with an attribute 
 ev_enabled. It will have the same possible values and a new command, 

I assume there'd be no intention of supporting on-the-fly changes of
this setting (ie, you'd set the GUC variable once at session startup
and not change thereafter)?  Otherwise you'd have a problem with cached
plans.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


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 easily confused with Normal.  Perhaps a less
mistake-prone coding would be

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
original proposal is better (using both 0 and O would be Real Bad),
but your use of normal and replica in the followup makes me wonder
which terminology is more common.

regards, tom lane

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate