Re: pg_get_publication_tables() output duplicate relid - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_get_publication_tables() output duplicate relid
Date
Msg-id CAA4eK1LT+Wf87tML9dKDu_AZMaMdYUC59XcA+ELr1yUbkot4tQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_get_publication_tables() output duplicate relid  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pg_get_publication_tables() output duplicate relid
List pgsql-hackers
On Mon, Nov 15, 2021 at 7:12 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?
>

I think it could provide flexibility to users to later change
"publish_via_partition_root" option. Because when that option is
false, we use individual partitions schema to send changes and when it
is true, we use root table's schema to send changes. Added Amit L. to
know if he has any thoughts on this matter as he was the author of
this work?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: CREATE PUBLICATION should "See Also" CREATE SUBSCRIPTION
Next
From: Daniel Gustafsson
Date:
Subject: Re: Allow CURRENT_ROLE in GRANTED BY