Re: ENABLE/DISABLE CONSTRAINT NAME

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: wangshuo(at)highgo(dot)com(dot)cn, Peter Eisentraut <peter_e(at)gmx(dot)net>, David Johnston <polobo(at)yahoo(dot)com>, 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-24 14:38:55
Message-ID: CA+TgmoY0EV6SG3kKHdcBbG7qm7m7ebYA8UeJZiLRhamuSufFsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 24, 2013 at 5:58 AM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
> --On 13. September 2013 20:17:19 -0400 Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
>> You're missing the point. Peter wasn't worried that your patch throws
>> an error; he's concerned about the fact that it doesn't.
>>
>> In PostgreSQL, you can only create the following view because test1
>> has a primary key over column a:
>>
>> => create table test1 (a int constraint pk primary key, b text);
>> => create view test2 as select a, b from test1 group by a;
>> => alter table test1 drop constraint pk;
>>
>> The reason that, if the primary key weren't there, it would be
>> ambiguous which row should be returned as among multiple values where
>> a is equal and b is not. If you can disable the constraint, then you
>> can create precisely that problem.
>
> Hmm not sure i understand this argument either: this patch doesn't allow
> disabling a primary key. It only supports FKs and CHECK constraints
> explicitly.

Well, that is certainly one way of skating around the specific concern
Peter raised.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-09-24 14:39:21 Re: record identical operator
Previous Message Robert Haas 2013-09-24 14:35:34 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE