Re: BUG #15587: Partitions with ALTER TABLE ADD CONSTRAINT

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15587: Partitions with ALTER TABLE ADD CONSTRAINT
Date: 2019-01-22 08:00:19
Message-ID: da033853-8185-9cae-8b64-0c03718a255d@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2019/01/22 1:29, Alvaro Herrera wrote:
> On 2019-Jan-21, Amit Langote wrote:
>> With this,
>> ALTER TABLE ADD FOREIGN KEY's inheritance recursion path now looks
>> completely different from ALTER TABLE ADD CHECK's, but that's fine.
>> Actually, if we had the same "clone" approach for check constraints, which
>> both checks if a child already has the constraint being cloned and creates
>> one if not, we could do away with errors like the following:
>>
>> create table p (a int, constraint check_a check (a > 0)) partition by list
>> create table p1 (a int);
>> alter table p attach partition p1 for values in (1);
>> ERROR: child table is missing constraint "check_a"
>>
>> But of course that would be a different feature.
>
> Heh, I wasn't aware that this failed in this silly way. But yeah,
> that's a different feature and we would certainly not backpatch a fix
> for it.

Are you be willing to try to fix that in HEAD if someone sends a patch? :)

Thanks,
Amit

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-01-22 23:31:27 BUG #15603: LibPQ doesn't like replication as a valid option
Previous Message PG Bug reporting form 2019-01-22 06:06:20 BUG #15602: pg_dump archive items not in correct section order