On Thu, Feb 23, 2006 at 12:36:30AM -0600, Jim C. Nasby wrote:
> On Thu, Feb 23, 2006 at 03:02:14PM +1100, Gavin Sherry wrote:
> > On Wed, 22 Feb 2006, Darcy Buskermolen wrote:
> > 
> > > On Wednesday 22 February 2006 08:48, Marc G. Fournier wrote:
> > > > Is there any work being done on Slony-I replicating DDL's?
> > > > And, of course, setting up replication on any TABLES created
> > > > in the process?
> > >
> > > No there is not any work on this.. in order to support this it
> > > would require hacks to the PG backend..  This could probably be
> > > done with Gavin's system table trigger patches.  The patches
> > > were never accepted for inclusion by core.
> > 
> > The issue, for me, is that there are two ways we could go about
> > implementing this and both have problems.
> > 
> > 1) Create triggers on individual system tables.
> > 
> > If you wanted to know when a new table was created, when a table
> > was modified or dropped, you would create a trigger on pg_class, I
> > suppose.  The problem, though, is that you might want to see what
> > columns a new table has but are they visible yet? It's a bit of a
> > can of worms.
> 
> Visible?? You mean you're worried about about seeing stuff that
> hasn't committed yet?

Well, yes.  I frequently will ensure that DDL changes happen
consistently by putting them inside a transaction, and this would be
on point.  That, or I've completely misunderstood the issue at hand.

> > 2) Create triggers on DDL
> > 
> > This seems to make more sense. You create a trigger on CREATE
> > TABLE. I'm not sure what you would pass the trigger in terms of
> > data, but say you managed to pass in some representation of the
> > data surrounding the DDL itself. There's a problem: what if people
> > touch the system tables by hand?
> 
> Are there any operations (other than CREATE DATABASE) that don't
> touch a system table?
> 
> > There are other problems which plague both approaches: who has
> > permission to create such a trigger? What does CREATE TRIGGER ON
> > CREATE DATABASE mean? It's actually impossible to fire such
> > triggers, it could be argued, because they affect every database.
> > This is also the case for CREATE USER/ROLE, because it is a global
> > operation.
> >
> > It is far from a straight forward concept. The thing is though,
> > the Slony project is not the only project which wants such
> > functionality: the JDBC and other interface providers could
> > greatly benefit because it would mean that their client side
> > metadata caching could be much more efficient.
> 
> Absolutely. I think there's a ton of uses for this, including many
> end-user applications (which is what slony is anyway...)

<aol>Me, too!</>

Cheers,
D
-- 
David Fetter david at fetter.org http://fetter.org/
phone: +1 415 235 3778

Remember to vote!