Re: Skipping schema changes in publication

On Mon, 16 Feb 2026 at 12:45, shveta malik <shveta.malik@gmail.com> wrote:
>
> On Mon, Feb 16, 2026 at 11:55 AM David G. Johnston
> <david.g.johnston@gmail.com> wrote:
> >
> > On Sunday, February 15, 2026, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >>
> >> On Mon, Feb 16, 2026 at 8:50 AM vignesh C <vignesh21@gmail.com> wrote:
> >> >
> >> I started looking into the patch, I have a few comments/questions
> >>
> >> 1.
> >> +     <para>
> >> +      Similarly, if another publication includes the same table with a row
> >> +      filter, but it is also covered by a
> >> +      <literal>FOR ALL TABLES ... EXCEPT</literal> publication, the table is
> >> +      published without applying the row filter, since row filters cannot be
> >> +      specified for <literal>FOR ALL TABLES ... EXCEPT</literal> publications
> >> +      and such publications are therefore treated as having no row filter.
> >> +     </para>
> >>
> >> I did not understand what this paragraph is trying to explain?  what
> >> do you mean by it is covered by  FOR ALL TABLES ... EXCEPT, does it
> >> mean the relation is not excluded by EXCEPT?
> >
> >
> > I concur the wording is tough to parse.  “Covered” is probably not a good word to use.  Stick with either included or excluded.  In this case, the point being communicated is if two publications include a table and one doesn’t have a where clause a combining subscription will consider the where clause to be a constant true when combining the where clauses using OR.
> >
> > This wording basically already exists in create subscription.
>
> --yes, it exists already in doc ([1]) in the row-filter page.
>
> > This paragraph and the preceding one, which discuss “if another publication exists”, seems out of place in the create publication documentation.  This page should be restricted to only those behaviors that manifest when dealing with a single publication, detailing what it produces.
>
> If we want to mention it in brief, I still feel CREATE-PUBLICATION
> page is a good place. SImilar to how we mention in
> 'publish_via_partition_root' section. See 'There can be a case where a
> subscription combines multiple publications.' in [2].
>
> Overall, I think this complete paragraph could be removed from
> CREATE-PUBLICATION. I find it over-detailed.
>
> +     <para>
> +      When a partition is listed in the <literal>EXCEPT</literal> clause of a
> +      <literal>FOR ALL TABLES</literal> publication with
> +      <literal>publish_via_partition_root</literal> set to
> +      <literal>true</literal>, the root partitioned table remains included in
> +      the publication. If that partition is explicitly included by another
> +      publication with <literal>publish_via_partition_root</literal> set to
> +      <literal>false</literal>, its changes are still replicated. In this
> +      case, the changes are published using the identity of the root
> +      partitioned table, since it is the top-most ancestor included in the
> +      <literal>FOR ALL TABLES</literal> publication, thereby ensuring
> +      consistent routing of changes within the partition hierarchy.
> +     </para>
> +     <para>
> +      Similarly, if another publication includes the same table with a row
> +      filter, but it is also covered by a
> +      <literal>FOR ALL TABLES ... EXCEPT</literal> publication, the table is
> +      published without applying the row filter, since row filters cannot be
> +      specified for <literal>FOR ALL TABLES ... EXCEPT</literal> publications
> +      and such publications are therefore treated as having no row filter.
> +     </para>
>
> Instead we can have something like below:
>
> There can be a case where a subscription includes multiple
> publications. In such a case, a table or partition that is included in
> one publication and listed in the EXCEPT TABLE clause of another is
> considered included for replication. Subscribing to multiple
> publications with different EXCEPT TABLE lists is currently not
> supported.

Updated

> ~~
>
> I feel it is unnecessary to mention row filters or column lists
> specifically in the context of the EXCEPT TABLE clause because IIUC:
>
> --They do not apply to FOR ALL TABLES publications, which is where
> EXCEPT TABLE is relevant.
> --In the case of multiple publications, the behavior of row filters
> and column lists remains unchanged from the HEAD behavior. The EXCEPT
> clause simply excludes the specified table; rest of the behaviour
> remains the same.
>
> Thoughts?

Agree, removed these

> ~~
>
>
> Few other comments on doc:
>
> 1)
> catalogs.sgml:
> prexcept:
> +       True if the relation is excluded from the publication.
>
> We shall use the term 'table' instead of 'relation' to refer clearly
> that it is a table and not a sequence.

Modified

> 2)
> logical-replication.sgml:
> +   <xref linkend="logical-replication-sequences"/>. When a publication is
> +   created with <literal>FOR ALL TABLES</literal>, tables can be explicitly
> +   excluded from publication using the
> +   <link linkend="sql-createpublication-params-for-except-table"><literal>EXCEPT
> TABLE</literal></link>
> +   clause.
>
> Suggestion:
> 'tables can be explicitly' --> 'a table or set of tables can be explicitly'

Modified

> 3)
> create_publication.sgml:
>
> +      For inherited tables, if <literal>ONLY</literal> is specified before the
> +      table name, only that table is excluded from the publication. If
> +      <literal>ONLY</literal> is not specified, the table and all its
> descendant
> +      tables (if any) are excluded. Optionally, <literal>*</literal> can be
> +      specified after the table name to explicitly indicate that descendant
> +      tables are excluded.
> +     </para>
> +     <para>
> +      For partitioned tables, when a table is specified in EXCEPT TABLE, then
> +      changes to that table and all of its partitions (that is, the entire
> +      partition subtree rooted at that table) are not replicated. This behavior
> +      is the same regardless of whether
> +      <literal>publish_via_partition_root</literal> is set to
> +      <literal>true</literal> or <literal>false</literal>. The
> +      <literal>publish_via_partition_root</literal> setting only determines
> +      which relation is used as the publishing relation for replicated changes,
> +      and does not affect exclusion semantics.
>
> a)
> Can we make the tone of both paragraphs the same? Suggestion:
> For partitioned tables, if a table is specified in EXCEPT TABLE, that
> table and all of its partitions (that is, the entire partition subtree
> rooted at that table) are excluded from the publication.
>
> b)
> This behavior
> +      is the same regardless of whether
> +      <literal>publish_via_partition_root</literal> is set to
> +      <literal>true</literal> or <literal>false</literal>. The
> +      <literal>publish_via_partition_root</literal> setting only determines
> +      which relation is used as the publishing relation for replicated changes,
> +      and does not affect exclusion semantics.
>
> I think there is no need to explicitly mention the
> 'publish_via_partition_root' thing here, unless others think
> otherwise.

Removed

Thanks for the comments. The attached v45 version patch has the
changes for the same.

Regards,
Vignesh