Casey Duncan wrote:
> On Sep 21, 2006, at 6:29 AM, Mikko Partio wrote:
> [..]
>
>>
>> Perhaps one solution would be a script that periodically scans both
>> _clustername.sl_table and pg_tables and would look for tables that are
>> on the system table but not on the slony table. From there the script
>> would create a new set and add the table to that set (and perhaps merge
>> the new set with an old set). What do you think, would this be a
>> feasible solution?
>
> A solution we came up with was to pass all sql ddl through an upgrade 
> script. The script would (simply) parse the incoming ddl looking for 
> 'create table/sequence' and 'drop table/sequence'. From the ddl it 
> would autogenerate the necessary slon commands to adjust the table set 
> (we use only one table set in our application). Then the ddl and slon 
> command would be applied.
>
> The restriction here of course is that all ddl must be funneled 
> through the upgrade script. This was not a problem for us since ddl 
> was only executed as part of a software release, and never ad-hoc on 
> the production cluster.
>
> -Casey
I have also considered the possibility that all ddl-commands would be 
executed through slonik's execute script -command. Then all that is left 
is to prevent users from executing ddl commands through psql. Would it 
be possible for you to send me the script(s) you are using?

The PGAdmin -alternative Dave Page mentioned seems interesting as well. 
Surprisingly Kubuntu Dapper has an ancient version of pgadmin which 
doesn't support slony so I can't try it out (at least for now).

MP