fix(postgres): keep a partitioned table's primary key inline - #212

The bug

pg_dump writes a partitioned parent's primary key as

ALTER TABLE ONLY public.readings ADD CONSTRAINT readings_pkey PRIMARY KEY (taken_on, id);

ONLY means the index reaches the partitions that exist at the moment it runs and no others. In pg_dump's own output order the key precedes every CREATE TABLE ... PARTITION OF, so they inherit it and the migration is correct.

Reorder the statements and it silently isn't. Grouping a fix set by object kind — every table created before any constraint is added — is a reasonable way to apply a migration, and SupaForge's orderStatements does exactly that (CREATE_TABLE phase 40 before ALTER_TABLE phase 50). The partitions are then created before the key is added, never receive it, and the migration reports success having dropped it.

This reached 3.0.0-rc.10. Every partitioned table with a primary key diffed by that release, on a machine with pg_dump, loses its partition keys when applied by a consumer that reorders. It surfaced as a SupaForge e2e failure whose fingerprint showed the partitions missing readings_2025_pkey / readings_2026_pkey, their indexes, and the inh attach links.

Introduced by 4e9c912 ("render DDL with pg_dump when it is available"), which put PgDumpRenderer::tableDDL() first in getCreateStatement for every table. rc.9 was immune because the built-in renderer emits the key inline.

The fix

Partition metadata is read before pg_dump is tried, so partitioned tables use the built-in renderer and get the key inside CREATE TABLE, where the statement order cannot matter.

The real fault is DDL whose correctness depends on the order it happens to be written in. This is also what the README already claimed — "Partitions always use the built-in renderer" — which stopped being true when pg_dump rendering began taking precedence.

Why the suite missed it

The corpus does cover partitioned tables with primary keys (obj_partitioned_range, obj_partition_index, hard_part_index_propagated), and those cases passed throughout.

The conformance runner applies DBDiff's statements in DBDiff's own order — the one order in which this bug is invisible. Nothing asserted that the emitted DDL survives being reordered.

So that is what the new test does. PartitionedTableRendererPostgresTest has two cases, both verified to fail without this change:

• the parent's key is inline and the DDL contains no ALTER TABLE ONLY
• the statements are replayed with every CREATE TABLE moved first, and each partition must still have its primary key — without the fix this fails with readings_2025 lost its primary key

The second encodes the property rather than the symptom, and is the one that would have caught the original regression.

I also considered and disproved two other explanations before finding this: that the stale pg_dump archive cache (#211) was hiding it, and that single-transaction application in the runner was masking it. Both were tested; neither holds.

Cost

One corpus case: hard_part_expr_key, an expression partition key that pg_dump reproduced and the built-in renderer does not. It was already in known-failures.json, so the baseline is unchanged and the suite reports no new failures. Measured back to back, twice each way, to be sure of the delta.

The README's figure and the reason for the exception are updated.

Test plan

• New test fails without the fix (both cases), passes with it
• Verified the fix is targeted, not a blanket disable: an ordinary table still renders via pg_dump, a partitioned parent does not
• Full conformance suite, both renderer modes: Failed (no diff): 0, zero new failures (304 with pg_dump, 291 built-in)
• 782 unit, 68 Postgres, 16 SQLite pass
• Corpus delta measured back to back in one session rather than from separate runs, after an initial single measurement proved to be an artifact of leftover scratch databases

🤖 Generated with Claude Code