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?

> 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...)
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461