API-created publications silently skip partitioned table data

[ttatsato]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

crates/etl-api/src/data/publications.rs builds publication DDL using
FOR TABLE ONLY ... (and SET TABLE ONLY ... on update), which causes
two issues when partitioned tables are involved.

Bug 1: ONLY is only applied to the first table

In PostgreSQL grammar:

TABLE table_and_columns [, ... ]
table_and_columns := [ ONLY ] table_name [ * ] [ ( column_name [, ...] ) ] [ WHERE ( expression ) ]

ONLY is a per-table prefix, not a clause-wide modifier. Today the code emits:

  CREATE PUBLICATION p FOR TABLE ONLY t1, t2, t3 WITH (publish_via_partition_root = true);

…which is parsed as: ONLY t1, then t2 and t3 with descendants included.
Behavior is silently inconsistent depending on table order.

Relevant code:

• create_publication — publications.rs:23-53
• update_publication — publications.rs:55-79

Bug 2: ONLY and publish_via_partition_root = true are contradictory for partitioned roots

publish_via_partition_root = true is the supported configuration for partitioned tables in this project.
That validation tells users to set publish_via_partition_root = true, but the API-created publication uses FOR TABLE ONLY <partitioned_root>, which excludes the partitions from the publication entirely.

Result: even when pipeline.rs validates the publication as "correctly configured", changes on the underlying partitions are not replicated, because the partitions are not part of the publication.

This is invisible at create time and only manifests as missing data downstream.

To Reproduce

CREATE TABLE parent (id int, ts date) PARTITION BY RANGE (ts);
CREATE TABLE parent_p1 PARTITION OF parent FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

-- What the API emits today:
CREATE PUBLICATION p FOR TABLE ONLY parent
  WITH (publish_via_partition_root = true);

INSERT INTO parent VALUES (1, '2026-01-15');  -- routed to parent_p1

SELECT schemaname, tablename FROM pg_publication_tables WHERE pubname = 'p';
--   schemaname | tablename
--  ------------+-----------
--   public     | parent
--
-- parent_p1 is NOT in the publication, so its DML is not replicated,
-- even though publish_via_partition_root = true is set.

Expected behavior

My current thinking is to drop ONLY entirely from the publication creation/update paths. Rationale:
The publish_via_partition_root = true contract from #410 assumes partitions are part of the publication, which FOR TABLE <root> (without ONLY) gives us.

Screenshots

System information

Additional context

Affected sites:

• create_publication — publications.rs:32
• update_publication — publications.rs:63
• (Will also need to be applied consistently to the new ADD/DROP/SET TABLE
  endpoints introduced in feat(etl-api): Add publication endpoints #748.)

Related

• feat(core): Add partitioned table support #410 — partitioned table support; established the publish_via_partition_root = true contract
• feat(etl-api): Add publication endpoints #748 — new publication endpoints; built on the same ONLY pattern, so the fix should land together

[iambriccardo]

Thanks for reporting this! Will investigate

[iambriccardo]

Thanks for the detailed report. I checked this against PostgreSQL behavior and the current API code.

You are right that we should not be emitting ONLY here. In FOR TABLE ONLY t1, t2, ONLY applies to t1 only, not the whole table list, so it can produce inconsistent behavior for descendant/inheritance tables depending on table order. I’ve removed ONLY from the API-created publication create/update paths.

One nuance: I was not able to reproduce the “partition data is skipped” part for declarative partitioned tables. PostgreSQL’s docs say partitions of a published partitioned table are implicitly considered part of the publication, and a local replication check confirmed that CREATE PUBLICATION p FOR TABLE ONLY parent WITH (publish_via_partition_root = true) still publishes DML routed to parent_p1. pg_publication_tables only showing the root is expected and does not by itself mean partition DML is excluded.

So I’m treating the fix as: remove the unnecessary and potentially confusing ONLY, while keeping publish_via_partition_root = true. If you have a concrete repro where partition DML is skipped despite that, please share the PostgreSQL version and replication/subscription setup so we can chase that separately.

[ttatsato]

Thank you for the quick follow-up and for digging into this !

[iambriccardo]

Thanks to you for your help!