Re: inherited primary key misbehavior - Mailing list pgsql-hackers

From Amit Langote
Subject Re: inherited primary key misbehavior
Date
Msg-id a09708e1-6cb3-71bc-56fb-22ba9c5b9beb@lab.ntt.co.jp
Whole thread Raw
In response to Re: inherited primary key misbehavior  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: inherited primary key misbehavior  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 2019/01/24 6:10, Alvaro Herrera wrote:
> Hello
> 
> On 2019-Jan-23, Amit Langote wrote:
> 
>> It seems that ATExecDetachPartition misses to mark a child's primary key
>> constraint entry (if any) as local (conislocal=true, coninhcount=0), which
>> causes this:
>>
>> create table p (a int primary key) partition by list (a);
>> create table p2 partition of p for values in (2);
>> alter table p detach partition p2;
>> alter table p2 drop constraint p2_pkey ;
>> ERROR:  cannot drop inherited constraint "p2_pkey" of relation "p2"
> 
> Ugh.
> 
> I suppose unique keys would have the same problem, so the check for
> indisprimary is wrong.

Fixed in the attached.  We don't support inheriting EXCLUSION constraints
yet, so no need to consider their indexes.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Delay locking partitions during INSERT and UPDATE
Next
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons