On Feb 22, 2006, at 4:46 PM, Marc G. Fournier wrote:

> On Wed, 22 Feb 2006, Jim C. Nasby wrote:
>
>> On Wed, Feb 22, 2006 at 09:07:29AM -0800, 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.
>>
>> Any idea why? Being able to detect changes to tables certainly seems
>> like a good capability to have, beyond just Slony.
>
> Just to jump in here, but I believe the issue is that you can't put a
> trigger on a system table, which Gavin's patch apparently tries to  
> address
> ... if a trigger could be put onto something like pg_class, to  
> detect a
> table being added/removed, then the subsequent transmassion of an
> appropriate CREATE command to the slave(s) wouldn't be too big of  
> an issue

This seems like a good idea to me.  Even if you don't want to put  
forth effort to support DDL operations within an application it  
protects against mistakes by the db admin.  What if your dba forgets  
to execute your ddl statements in slonk (or whatever it's called) and  
accidentally runs them in psql.  Now they don't get replicated.  Now  
you are replicating to a database with different table definitions.   
What if the statements to be replicated are now invalid on the slave  
but valid on the master.  What happens then?

I agree that your admin should not be stupid and make a mistake like  
that but there is no point in making it easier to shoot yourself in  
the foot.  It would be nice to be able to just update the master to  
your hearts content have the slaves get updated as well.

What are the possible drawbacks to this?  Why make the replication  
harder to manager than it has to be?  Does anyone know why the patch  
was rejected?

Rick