Re: ENABLE/DISABLE CONSTRAINT NAME
От | David Johnston |
---|---|
Тема | Re: ENABLE/DISABLE CONSTRAINT NAME |
Дата | |
Msg-id | 1378167324857-5769337.post@n5.nabble.com обсуждение исходный текст |
Ответ на | Re: ENABLE/DISABLE CONSTRAINT NAME (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: ENABLE/DISABLE CONSTRAINT NAME
|
Список | pgsql-hackers |
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? 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. 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. -- View this message in context: http://postgresql.1045698.n5.nabble.com/ENABLE-DISABLE-CONSTRAINT-NAME-tp5769136p5769337.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
В списке pgsql-hackers по дате отправления: