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.

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?

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.

Thoughts?

Gavin