Re: Disable and enable of table and column constraints

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

In response to

Browse pgsql-hackers by date

  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