On 9/10/2009 11:06 AM, Tom Lane wrote:
> Christopher Browne <cbbrowne@ca.afilias.info> writes:
>> With the ALTER TABLE DISABLE TRIGGER functionality added in 8.3, we
>> already have the ability to do this with foreign key constraints.
>
> That "feature" is a crock that should not be extended, because it
> leaves it entirely on the user's shoulders whether the constraint
> is actually true when the system thinks it is. What is being discussed
> here is ways to incrementally add real, proven-valid constraints.
>
> (Indeed, given the thought that's being given to having the planner
> assume that FK constraints hold, I rather think that we need to
> reconsider ALTER DISABLE TRIGGER.)
The feature was originally intended to be a clean way of avoiding
interferences of triggers and/or foreign keys with replication systems
that work on the user level (like Bucardo, Londiste and Slony). The only
way to break foreign keys in that scenario is to replicate a referencing
table without replicating the corresponding PK table.
Note that Slony-I currently does apply updates in a fashion that would
actually make checking of foreign keys on the replica possible, but does
need the ability to disable regular user triggers. But for some future
version of Slony, we may need to change that and apply changes within
one replication group (SYNC) out of order with respect to multiple
tables. Which means that Slony would need at least some mechanism to
disable user triggers and force all foreign key constraints to be
deferred, whether they are declared deferrable or not.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin