I had a chat with Jan about some of the forthcoming changes we're
thinking about for the next major version...

In general, there's a thought of doing a fairly *enormous* amount of
cleanup, falling fundamentally out of the presence of hooks in PG 8.3
that will allow Slony-I to work without any of the current catalog
corruptions.  The cleanup we're thinking of is of extensive enough
nature that it might even be that "version 2.0" would only work with
PG 8.3 'and above.'

The scope of that, in total, I'll let Jan comment on, so as to allow
debate on the merits of that.

I'll draw back to a rather smaller, but not unimportant, matter...

My position at this point is that dropping the "TABLE ADD KEY" feature
is highly desirable.  It represents a schema corruption that causes
considerable trouble, and discouraging its use to the point of
promising it *won't* be supported in 2.0 strikes me as being a good
starting position.

Let me note a merit that falls from this; at present, uninstalling
Slony-I from a node requires walking thru tables and doing the
following:

- dropping the generated columns
- dropping denyaccess triggers
- fixing the expressly broken other triggers

After those three things, DROP SCHEMA _Whatever completes the work.

In 8.3, "fixing the triggers" is eliminated as a step because the
triggers don't need to be "busted."  If we eliminate TABLE ADD KEY,
then there are no generated columns to drop out.

That leaves dropping the denyaccess triggers, but "DROP SCHEMA
_Whatever CASCADE" actually automatically addresses that.

There, essentially, is my argument as to why getting rid of TABLE ADD
KEY is a good thing.  It eliminates, conceptually, about 1/2 of the
"brokenness" about the way Slony-I presently "busts" the
catalog/schema...
-- 
(format nil "~S@~S" "cbbrowne" "linuxfinances.info")
http://linuxdatabases.info/info/multiplexor.html
"Every  sufficiently    unreadable programming  language   contains  a
reimplementation  of  APL and/or INTERCAL."    -- Greenspun's Eleventh
Rule of Programming