Re: ENABLE/DISABLE CONSTRAINT NAME

From: wangshuo(at)highgo(dot)com(dot)cn
To: David Johnston <polobo(at)yahoo(dot)com>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: ENABLE/DISABLE CONSTRAINT NAME
Date: 2013-09-03 07:13:18
Message-ID: 69d69a640cea999cda555acc120b508d@highgo.com.cn
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

于 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-09-03 07:51:04 Re: UTF8 national character data type support WIP patch and list of open issues.
Previous Message Peter Geoghegan 2013-09-03 04:59:42 Re: INSERT...ON DUPLICATE KEY IGNORE