From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com> |
Cc: | "Christopher Browne" <cbbrowne(at)ca(dot)afilias(dot)info>, <pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Disable and enable of table and column constraints |
Date: | 2009-09-14 14:30:18 |
Message-ID: | 4AAE0D2A020000250002AECC@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
> FWIW, I find the ability in Slony to configure triggers so they work
> or not depending on the replication role to be extremely useful.
> Absolutely a major positive feature.
Yeah, as a general rule it doesn't make sense to try to enforce
constraints on a replication *target*. Check and report, perhaps, but
you don't normally want to error out on anything which you know was
actually applied to the source database. It's even worse for some
classes of triggers which generate derived data; you don't want the
replication to generate one value and then a trigger on the
replication target to try to do the same. A count, for example, could
easily wind up with an "off by one" error much of the time.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2009-09-14 14:48:49 | Re: BUG #5053: domain constraints still leak |
Previous Message | Pierre Frédéric Caillaud | 2009-09-14 14:26:53 | Bulk Inserts |