On Mon, Feb 16, 2026 at 11:55 AM David G. Johnston <[email protected]> wrote: > > On Sunday, February 15, 2026, Dilip Kumar <[email protected]> wrote: >> >> On Mon, Feb 16, 2026 at 8:50 AM vignesh C <[email protected]> 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. ~~ 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? ~~ 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. 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' 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. ~~ [1]: https://www.postgresql.org/docs/current/logical-replication-row-filter.html#LOGICAL-REPLICATION-ROW-FILTER-COMBINING [2]: https://www.postgresql.org/docs/current/sql-createpublication.html#SQL-CREATEPUBLICATION-PARAMS-WITH-PUBLISH-VIA-PARTITION-ROOT thanks Shveta
