On Wed, Feb 25, 2026 at 4:01 PM shveta malik <[email protected]> wrote: > > On Mon, Feb 23, 2026 at 4:46 PM Amit Kapila <[email protected]> wrote: > > > > On Mon, Feb 23, 2026 at 11:37 AM Shlok Kyal <[email protected]> > > 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
