PostgreSQL 15 RC1 settles schema publication syntax

Selecting a schema for logical replication expresses a continuing rule. It can include tables created after the publication definition, so it has a different scope from enumerating the tables that happen to exist today. PostgreSQL 15 brings that distinction into publication syntax, and its first release candidate makes a final adjustment to how the rule is written.

The September 29 RC1 announcement changes the syntax to CREATE PUBLICATION ... FOR TABLES IN SCHEMA .... It also permits a publication to name both a schema and a table within it, while rejecting schema publication combined with table column lists. These changes make the release candidate useful for testing actual publication definitions, including their edge cases.

I value PostgreSQL for letting relational structure remain explicit. A schema-wide replication rule is useful when the schema itself is the intended boundary. It also deserves a precise reading, because future table creation can change what that rule includes without another publication command.

A schema definition includes future tables

The CREATE PUBLICATION documentation at the RC1 tag says FOR TABLES IN SCHEMA includes tables created in the named schemas in the future. For illustrative existing schemas called sales and marketing, the definition takes this form.

CREATE PUBLICATION sales_publication
FOR TABLES IN SCHEMA marketing, sales;

The definition describes publication membership. It does not begin replication by itself. A publication groups and filters changes for future subscribers. This separates defining what may be published from establishing a subscription that consumes it.

The supported relation types remain restricted. Persistent base tables and partitioned tables can participate. Temporary tables, unlogged tables, foreign tables, and views are excluded, including materialized views. Naming a schema therefore does not mean every database object within that namespace becomes a replicable table.

Creating a schema-wide publication also requires superuser authority. The documentation distinguishes that from adding individually named tables, which requires ownership rights on those tables. The difference fits the continuing nature of schema membership. An explicit list and a rule accepting future tables are different administrative commitments.

Partition membership can cross the schema boundary

For a partitioned table included through schema publication, existing and future partitions implicitly participate. The documentation explicitly includes partitions outside the publication schema. Direct operations on such a partition are still published through the publication containing its ancestor.

That behavior follows the partitioned table relationship rather than treating each partition solely as an unrelated table in a namespace. A schema name is therefore insufficient to describe the full set of physical tables whose changes can be published. The partition tree also matters.

This is a practical consequence of selecting the root as part of the published structure. Moving or creating a partition in another schema does not, by itself, establish that the partition lies outside the publication. A description of the replication boundary needs to account for the published ancestor.

I find that detail more useful than a general instruction to inspect replication after a schema change. It tells an administrator which relationship determines membership. The rule can be understood before a new partition exists.

Column selection has a deliberate restriction

RC1 rejects publications that combine schema-level inclusion with a table column list. The announcement identifies that as a change since Beta 4, and the versioned command documentation states the restriction in both the table-list and schema-list descriptions. A schema-wide definition and a per-table projection cannot be combined in that publication.

For individually selected tables, column lists remain available. Omitting a list means all columns participate, including columns added later. Specifying a list limits replication to the named columns. Updates and deletes also require the replica-identity columns to be included, because those operations need to identify the row at the destination.

The command documentation also says a row filter becomes redundant when the same table is included through a named schema. This is another example where a broad membership rule changes the meaning of a narrower table-level choice. Reading each clause independently can therefore give an incorrect account of the resulting publication.

DDL is not published through this mechanism. Selecting a schema for data changes does not replicate every schema modification into the subscriber. The publication rule determines the set of tables whose relevant data changes belong to the stream. It does not turn logical replication into a complete copy of all database administration operations.

RC1 is close to release without being the release

The announcement says the candidate should be mostly identical to the initial PostgreSQL 15 release, while allowing for additional fixes. It gives October 13 as the planned general-availability date, conditional on finding no issue that warrants delay or another candidate. As of this announcement, that remains a schedule rather than a completed release.

The candidate also repairs the publication-table view displaying dropped columns and several backup or recovery issues. Those entries reinforce the purpose of the candidate stage. The remaining work includes making the new behavior and its inspection tools agree, not only stabilizing syntax accepted by the parser.

Upgrading from an earlier PostgreSQL version to this candidate uses a major-version strategy such as pg_upgrade or dump and restore. The maintenance-update procedure for the preceding major version does not apply merely because the new software is close to final. For publication testing, RC1 provides the concrete syntax and restrictions that an application or administrative definition can exercise before the planned release date.