On Tue, Nov 16, 2021 at 7:21 AM houzj.f...@fujitsu.com <houzj.f...@fujitsu.com> wrote: > > On Mon, Nov 15, 2021 9:42 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > > On Mon, Nov 15, 2021 at 1:48 PM houzj.f...@fujitsu.com > > > <houzj.f...@fujitsu.com> wrote: > > > > > > create table tbl1 (a int) partition by range (a); create table > > > > tbl1_part1 partition of tbl1 for values from (1) to (10); create > > > > table tbl1_part2 partition of tbl1 for values from (10) to (20); > > > > create publication pub for table tbl1, tbl1_part1 with > > > > (publish_via_partition_root=false); > > > > In the name of consistency, I think this situation should be an error -- I > > mean, if > > we detect that the user is trying to add both the partitioned table *and* > > its > > partition, then all manner of things are possibly going to go wrong in some > > way, > > so my inclination is to avoid it altogether. > > > > Is there any reason to allow that? > > > > If we do that, then we have to be careful with later ALTER PUBLICATION > > too: adding a partition is not allowed if its partitioned table is there, > > and adding > > a partitioned table should behave in some sensible way if one of its > > partitions is > > there (either removing the partition at the same time, or outright > > rejecting the > > operation.) > > Thanks for the response. > > If we decide to disallow this case, we seem need to handle some other cases as > well, for example: We might also need additional check when ATTACH a > partition, > because the partition's parent table could already be published in the same > publication as the partition. >
What kind of additional checks you are envisioning and why? -- With Regards, Amit Kapila.
