RE: Skipping schema changes in publication

On Monday, February 23, 2026 7:16 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> 
> On Mon, Feb 23, 2026 at 11:37 AM Shlok Kyal <shlok.kyal.oss@gmail.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.

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