[EMAIL PROTECTED] ("Marko Kreen") writes: > Also the design should be based on assumption that the target side > is exactly in sync. Eg. DROP CASCADE should be replicated as DROP CASCADE. > We should not make scheme more complex to survive cases where target > is not in sync. That way madness lies. The effect should be like > same SQL statements are applied to target by hand, no more, no less.
We have, already, in 8.4, a handling of triggers for TRUNCATE; the reason why support hasn't made it into Slony-I yet relates quite exactly to this... The trouble comes in if you do TRUNCATE CASCADE; I'm not quite sure how to collect together the multiple recordings of the trigger functions that would be collected as a result; for it all to work, safely, on the remote node, we'd need to apply all of those truncates at once. Note also that there is an issue with coordination of schemas; Slony-I shuts off the RI triggers on subscribers, so that the target is fairly certain to not be *entirely* in sync, by express intent. Those are legitimate differences between source and target. -- select 'cbbrowne' || '@' || 'linuxfinances.info'; http://cbbrowne.com/info/lsf.html Rules of the Evil Overlord #145. "My dungeon cell decor will not feature exposed pipes. While they add to the gloomy atmosphere, they are good conductors of vibrations and a lot of prisoners know Morse code." <http://www.eviloverlord.com/> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers