On Mon, Oct 05, 2009 at 11:48:07AM -0700, Gordon Shannon wrote: > > I beg to disagree with those who say you MUST or even SHOULD use execute > script to create a table with a foreign key to a replicated table. In the > same way that I can drop or add a key to a replicated table directly on the > slave, I would not expect Slony to care about the new foreign key reference. > Can anyone say what bad things might happen of which I am unaware?
The problem is that FKs are implemented in Postgres by triggers, and the trigger will then get created on the replica. Since it's messing with the catalogues for an _existing_ table, you might get surprises (one of the triggers needs to be on the referred-to table. See V's original question -- that's the "implicit trigger" he asked about). This is always the nasty corner with the old catalogue-munging Slony did. One thing I'm _not_ sure of (I'm showing how I'm getting out of practice) is how any of this interacts with the newer trigger types (and the 2.x Slony required to use them). It could be that they won't have trouble; I know that getting around this issue was one of the main goals of the work, but I stopped working on Postgres before I had to pay attention to the results. I probably should have been more clear that there might be a case where it's no longer needed. A -- Andrew Sullivan [email protected] _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
