On Fri, Nov 8, 2024 at 2:54 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > On 2024-Nov-07, Amit Langote wrote: > > > On Wed, Nov 6, 2024 at 9:34 PM Alvaro Herrera <alvhe...@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
