On Thu, 8 Feb 2007, Joshua D. Drake wrote:
> Well how deep are we talking here? My understanding of what Jan wants to
> do is simple.
> Be able to declare which triggers are fired depending on the state of
> the cluster.
> In Jan's terms, the Origin or Subscriber. In Replicator terms the Master
> or Slave.
> This is useful because I may have a trigger on the Master and the same
> trigger on the Slave. You do not want the trigger to fire on the Slave
> because we are doing data replication. In short, the we replicate the
> result, not the action.
> However, you may want triggers that are on the Slave to fire separately.
> A reporting server that generates materialized views is a good example.
> Don't tie up the Master with what a Slave can do.
It'd be great if Jan considers the blending of replication; any given DB
instance shouldn't be only a master/originator or only a slave/subscriber.
A solution that lets you blend replication strategies in a single db is,
from my point of view, very important.
> > I have no clue what got you into what you are doing here.
Jan, some sleep now and then might be helpful to your public disposition.
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
[EMAIL PROTECTED], http://ScienceTools.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend