On Fri, Nov 8, 2024 at 2:54 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2024-Nov-07, Amit Langote wrote:
>
> > On Wed, Nov 6, 2024 at 9:34 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> > > Oh, hmm, that makes sense I guess. Still, while this restriction makes
> > > sense for inheritance, it doesn't IMO for partitioned tables. I would
> > > even suggest that we drop enforcement of this restriction during ATTACH.
> >
> > I agree. Since leaf partitions have no children to propagate
> > constraints to, the NO INHERIT mark shouldn't matter. And partitioned
> > partitions already disallow NO INHERIT constraints as you mentioned.
> >
> > Do you think we should apply something like the attached at least in
> > the master? I found that a similar restriction exists in the CREATE
> > TABLE PARTITION OF path too.
>
> Yeah, that sounds reasonable. I didn't look at the code in detail, but
> I'm not sure I understand why you'd change CREATE TABLE PARTITION OF,
> since the point is that this restriction would apply when you attach a
> table that already exists, not when you create a new table. Maybe I
> misunderstand what you're saying though.
The restriction also exists in the CREATE TABLE PARTITION OF path:
create table parted_parent (a int, constraint check_a check (a > 0))
partition by list (a);
-- leaf partition
create table parted_parent_part1 partition of parted_parent
(constraint check_a check(a > 0) no inherit) for values in (1);
ERROR: constraint "check_a" conflicts with inherited constraint on
relation "parted_parent_part1"
-- non-leaf partition
postgres=# create table parted_parent_part1 partition of parted_parent
(constraint check_a check(a > 0) no inherit) for values in (1)
partition by list (a);
ERROR: constraint "check_a" conflicts with inherited constraint on
relation "parted_parent_part1"
I think we can remove the restriction at least for the leaf partition
case just like in the ATTACH PARTITION path.
> > Though if we decide to apply the attached, does the note "not marked
> > NO INHERIT" become unnecessary?
>
> Yes -- I think your patch would have to remove it again. A short-lived
> note for sure, but I thought it was better to have all branches in the
> same state, and now you can modify master.
Ok, got it.
--
Thanks, Amit Langote
