On Mon, Nov 15, 2021 9:42 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On Mon, Nov 15, 2021 at 1:48 PM houzj.fnst@fujitsu.com
> > <houzj.fnst@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. During the check we might also need to lock all
the parent tables to handle concurrently change which looks complicated to me :(
I am not sure is it worth adding these lock and check. Maybe we can leave the current
behavior as is ?
Best regards,
Hou zj
