Re: Disable and enable of table and column constraints

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