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
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
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
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
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
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.
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo