Re: ENABLE/DISABLE CONSTRAINT NAME
От | wangshuo@highgo.com.cn |
---|---|
Тема | Re: ENABLE/DISABLE CONSTRAINT NAME |
Дата | |
Msg-id | 69d69a640cea999cda555acc120b508d@highgo.com.cn обсуждение исходный текст |
Ответ на | Re: ENABLE/DISABLE CONSTRAINT NAME (David Johnston <polobo@yahoo.com>) |
Ответы |
Re: ENABLE/DISABLE CONSTRAINT NAME
Re: ENABLE/DISABLE CONSTRAINT NAME |
Список | 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 по дате отправления: