Andrew Sullivan wrote: > On Thu, Apr 19, 2007 at 09:52:24AM -0700, Andrew Hammond wrote: > >> Others have provided ample advice on how to remove the slony stuff inside >> the database, but briefly, on the master DROP SCHEMA _my_slony_cluster >> CASCADE; >> > > Will that get rid of the triggers on the user tables? This might be > a good way to cause all transactions to fail. I'd make sure you get > rid of the slony triggers first. > > A > Yes, that will get rid of the Slony-I-created triggers (e.g. - the logtriggers), because those triggers are tied to functions in the _my_slony_cluster schema.
PostgreSQL *is* smart enough to look at the CASCADE linkage and, in effect, say "Hmm. I'm dropping the function _my_slony_cluster.logtrigger(). I'd better drop all the triggers that reference that function." There are two places where DROP SCHEMA ... CASCADE is specifically inadequate: 1. At present, certain triggers get hidden on subscriber nodes via a pg_catalog corruption whereby they get pointed to the PK index, away from the table. Those triggers do not get restored when you run DROP SCHEMA. 2. If one has used TABLE ADD KEY to introduce a funky-named extra column that is used as a candidate primary key, that column gets left alone, as it is deemed to be in the table's own schema. It would be really cool if there were some way of having that column be treated as being in the "_my_slony_cluster" schema, instead, but as objects aren't split across schemas that way, we can but consider TABLE ADD KEY to be a misfeature to remove in some future version of Slony-I ;-). But aside from those two places, DROP SCHEMA is pretty much smart enough... _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
