On Monday, February 23, 2026 7:16 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.
I agree that supporting exclusion of a partition while publishing its parent would add significant complexity and could be achieved independently. Another perspective I saw this is that the ability to exclude only a specific partition from a partition tree while continuing to publish changes via the root table introduces an entirely new mode that users couldn't achieve before this patch. Previously, once a parent table was added to a publication, all its partitions were published regardless of their schema, so users cannot exclude a partition either via FOR TABLE or FOR TABLES IN SCHEMA. Therefore, disallowing partition exclusion doesn't remove any existing capability, which seems acceptable. The original use case in this thread also doesn't mention partitioned tables, so I think EXCEPT TABLE provides value even without implementing this new ability. Given the amount of code required to support partition exclusion, it makes sense to me to treat this as an independent feature that can be pursued later based on user feedback. Best Regards, Hou zj
