From: | David Johnston <polobo(at)yahoo(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ENABLE/DISABLE CONSTRAINT NAME |
Date: | 2013-09-03 00:15:24 |
Message-ID: | 1378167324857-5769337.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-09-03 00:17:22 | Re: [v9.4] row level security |
Previous Message | Bruce Momjian | 2013-09-03 00:08:45 | Re: [v9.4] row level security |