Re: Skipping schema changes in publication

On Wed, Feb 25, 2026 at 4:01 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Mon, Feb 23, 2026 at 4:46 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Mon, Feb 23, 2026 at 11:37 AM Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
> > >
> > > I have also modified the error message as suggested by Shveta in [2].
> > > Attached the latest v48 patch.
> > >
> >
> > I see that the second patch (0002) brings complexity in the patch to
> > deal with following points: (a) The first complexity is if one of the
> > partitions is specified then how to compute the initial set of
> > relations to copy when pubviaroot is true. This is complex because we
> > need to exclude the partitions specified. (b) The other complexity is
> > combining Except list containing partitions and other publications
> > specifying partitions or partitioned tables both during replication
> > and probably during initial sync.
> >
> > I think it will be better if for the first version, we allow only root
> > partitioned table to be specified in the Except Table list. This would
> > mean that if the user tries to attach that root partition table to
> > another root then we should give an error. If we go via this route, it
> > will be important to allow users to remove some tables from the Except
> > list, so we can provide Alter Publication <pub_name> Set Except Table
> > (table_names).
> >
> > I think excluding specific partitions may also have some use cases but
> > adding additional complexity and maintenance effort is worth, if there
> > is a real field demand for such a feature.
> >
> > Thoughts?
> >
>
> I fully agree. The additional complexity does not appear to be worth
> the value right now, unless we receive meaningful user feedback that
> justifies implementing it.
>

I’m on the same page. The benefit probably doesn't justify the added
complexity and the long-term code maintenance overhead this would
introduce.

--
Regards,
Dilip Kumar
Google