| 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: | Whole Thread | Raw Message | 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 |