Re: ENABLE/DISABLE CONSTRAINT NAME

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.

In response to

Responses

Browse pgsql-hackers by date

  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