Re: pg_get_publication_tables() output duplicate relid

On Tue, Nov 16, 2021 at 7:21 AM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> 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.
>

What kind of additional checks you are envisioning and why?

-- 
With Regards,
Amit Kapila.