于 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
