Geoffrey <lists at serioustechnology.com> writes:
> As I've noted in the past, because of our software design, I can not
> use the 'execute script' process for adding a field to a table.  That
> being said, I'm looking for an alternative approach.  As it stands,
> when we need to add a table, we plan to shut slony down, create a new
> set for that table and restart slony.
>
> What would be the best way to add a field to a replicated table using
> this scenario?  That is, shutting slony down, making the change and
> starting slony back up.  I'm assuming that I can't simply add the
> field to both nodes and restart slony, but if that would work, that
> would be great.

Well, what you need to do, underneath it all, is to make sure that the
"shape" of the replication configuration for the table gets set up
properly on all nodes.

The "minimal relevant" bits seem to be be that:

 - Obviously, the attribute needs to be added to the table
   :-)

 - The logtrigger needs to be set up properly on the origin node

   Take a look at function alterTableForReplication(tab_id) in
   src/backend/slony1_funcs.sql

 - All of this needs to take place at a compatible place in the
   "update stream" so that you don't have some updates sitting in
   sl_log_* with the "old" schema and other with the "new, altered,
   with-extra-column" schema.

   Actually, that part shouldn't be a *big* deal; sl_log_* store fully
   qualified inserts and such, so hopefully that will "just work," as
   long as updates don't hit the subscriber until the new column has
   gotten added.

Now, I should be clear to disclaim any "warrantee" on this; if you
choose NOT to use the build-in mechanisms like "EXECUTE SCRIPT," you
have to accept that you're doing your own "open heart surgery" by
hand, and that this is decidedly more risky.

If you have expressly accepted development practices that don't
conform to how Slony-I works, then that's a pretty strong hint that
there's not a particularly good fit there.  I'd not be offended if you
concluded that "Slony-I is not suitable because we do X, Y and Z..."

The amount of "surgery" you seem to want to do concerns me somewhat...
It sounds likely to lead to an unhappy ending, and unhappy users
aren't what we want.
-- 
"cbbrowne","@","linuxdatabases.info"
http://linuxfinances.info/info/nonrdbms.html
Change is inevitable, except from a vending machine.