Re: ENABLE/DISABLE CONSTRAINT NAME

On 10/9/13 1:10 PM, Robert Haas wrote:
> On Tue, Sep 24, 2013 at 10:40 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
>>> Hmm not sure i understand this argument either: this patch doesn't
>>> allow disabling a primary key. It only supports FKs and CHECK
>>> constraints explicitly.
>>
>> Well, as soon as the patch for cataloging not-null constraints as check
>> constraints is available, it will be possible to create views that
>> depend functionally on check constraints.  Then you'll have the same
>> problem there.
>>
>> It's also not clear why this patch only supports foreign keys and check
>> constraints.  Maybe that's what was convenient to implement, but it's
>> not a principled solution to the general issue that constraints can be
>> involved in dependencies.
>
> I agree with these concerns, as well as those raised by Tom Lane and
> Fabien COELHO, and I think they indicate that we shouldn't accept this
> patch.  So I'm marking this as Rejected.

I see a use case for disabling FKs and CHECKS but not PKs or UNIQUE constraints: FKs and CHECKS don't depend on
additionalstate information (namely an index), so it's easy to just disable them temporarily and then re-enable them.
Thesame isn't true about a PK or UNIQUE constraint.
 

Of course we could decide to do something more complex to handle disabling PK/UNIQUE... though at that point it'd be
betterto just allow temporarily disabling any index. But I think there's an argument to be made for that being beyond
thescope of disabling "simple" constraints... it's a pretty high bar to set that we won't accept a patch that disables
simpleconstraints but not those involving indexes.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net