Re: ENABLE/DISABLE CONSTRAINT NAME - Mailing list pgsql-hackers

From wangshuo@highgo.com.cn
Subject Re: ENABLE/DISABLE CONSTRAINT NAME
Date
Msg-id 69d69a640cea999cda555acc120b508d@highgo.com.cn
Whole thread Raw
In response to Re: ENABLE/DISABLE CONSTRAINT NAME  (David Johnston <polobo@yahoo.com>)
Responses Re: ENABLE/DISABLE CONSTRAINT NAME
Re: ENABLE/DISABLE CONSTRAINT NAME
List pgsql-hackers
于 2013-09-03 08:15, David Johnston 回复:
> Jeff Davis-8 wrote
>> Is there any semantic difference between marking a constraint as
>> DISABLED and simply dropping it? Or does it just make it easier to
>> re-add it later?
>
David Johnston wrote:
> I cannot answer the question but if there is none then the main 
> concern I'd
> have is capturing "meta-information" about WHY such a constraint has 
> been
> disabled instead of dropped.

Drop/build and disable/enable constraint has no fundamental difference,
and could achieve the same purpose.What I do also more convenient for 
the user.
Recording the disabled constraints is easier than recoding all the 
constrains.
What's more, a lot of people ever asked about turing off constraint and
The sql2008 support this.So I think it's necessary in some ways.

> I guess this whole feature extends from the trigger disable feature 
> that
> already exists.  Given we have the one adding this seems 
> symmetrical...
>
> I cannot really see using either feature on a production system (if
> following best practices) but I can imagine where they could both be 
> helpful
> during development.  Note with this usage pattern the 
> meta-information about
> "why" becomes considerably less important.
>
> David J.


     Wang Shuo     HighGo Software Co.,Ltd.     September 3, 2013



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT...ON DUPLICATE KEY IGNORE
Next
From: Heikki Linnakangas
Date:
Subject: Re: UTF8 national character data type support WIP patch and list of open issues.