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(at)gmx(dot)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 additional state information (namely an index), so it's easy to just disable them temporarily and then re-enable them. The same 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 better to just allow temporarily disabling any index. But I think there's an argument to be made for that being beyond the scope of disabling "simple" constraints... it's a pretty high bar to set that we won't accept a patch that disables simple constraints but not those involving indexes.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net