From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
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-21 16:29:44 |
Message-ID: | 201901211629.gu3plkjjqefw@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2019-Jan-21, Amit Langote wrote:
> Sorry about the noise. I agree with the committed approach.
Great, thanks for checking.
> 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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-01-21 17:31:02 | Re: BUG #15600: ts_stat's nentry maxes out at 255 |
Previous Message | PG Bug reporting form | 2019-01-21 15:30:26 | BUG #15600: ts_stat's nentry maxes out at 255 |