Repository navigation
Preserve comments on table constraints and inherited partition constraints #674
Description
Problem
pgschema dump omits comments on table constraints, including distinct comments on inherited partition constraints. Replay loses those comments, while a subsequent plan can still be empty.
Reproduction
Create this schema in an empty source database:
CREATE TABLE events (id integer PRIMARY KEY) PARTITION BY RANGE (id);
CREATE TABLE events_leaf PARTITION OF events FOR VALUES FROM (0) TO (10);
COMMENT ON CONSTRAINT events_pkey ON events IS 'parent key';
COMMENT ON CONSTRAINT events_leaf_pkey ON events_leaf IS 'child key';Dump the source and replay the SQL into another empty database. Inspect both databases with:
SELECT t.relname, c.conname, obj_description(c.oid, 'pg_constraint')
FROM pg_constraint c
JOIN pg_class t ON t.oid = c.conrelid
JOIN pg_namespace n ON n.oid = t.relnamespace
WHERE n.nspname = 'public' AND c.contype = 'p'
ORDER BY t.relname, c.conname;The source has distinct parent and child comments. Replay has NULL comments.
Expected behavior
Dump, replay, and plan/apply should preserve comments on ordinary and partitioned table constraints. Comment-only changes should update comments without replacing constraints. The planner should support setting, changing, and removing comments, including child comments that differ from the parent.
Verification and scope
The equivalent UNIQUE-constraint case was reproduced with synthetic schemas on PostgreSQL 14–18 against main at 36a38ff3. The loss also occurs before #663, so this is an existing limitation.
Related to #653, #663, and closed PR #645. This report isolates table-constraint comments from INCLUDE columns, inherited-name restoration, and SQL-loader changes.
Activity
zikolach commentedon Oct 28, 2026
While working on #674, I found a prerequisite involving inherited constraint names. The relevant planner code is unchanged between
36a38ff3and currentmainatf2ebe96b.Reproductions
Consider this synthetic schema:
root_fk, losingcustom_fk.Once the inspector and planner preserve comments, a subsequent
COMMENT ON CONSTRAINT custom_fkorcustom_leaffails with SQLSTATE42704. The unpublished comment patch exposes the existing name loss.Possible implementation boundary
The existing explicit PK/UNIQUE family renderer is a useful starting point. Native PostgreSQL 14–18 probes confirm that an existing three-level PK family can be rebuilt with named
ALTER TABLE ONLY ... ADD CONSTRAINTstatements and bottom-upALTER INDEX ... ATTACH PARTITION, while retaining data and a standalone index occupying the generated leaf name.FK ownership needs a separate decision. Creating named child FKs before the parent works in simple families. However, consider an additional equivalent local FK named
aaa_local. After dropping the parent FK and recreatingcustom_fk, adding the parent FK adoptsaaa_localand leavescustom_fklocal. I reproduced this on PostgreSQL 14–18. Correct names alone are therefore insufficient evidence of correct ownership.The inspector currently discards ignored FK definitions. Their names alone cannot establish whether they compete for adoption. Rebuilding equivalent local FKs would change otherwise unchanged objects and require validation work. Rejecting filtered cases would change current migration behavior.
Would a separate constraint-family planning change be an acceptable direction before completing #674? I would like agreement on FK ownership and excluded-constraint handling before implementing that broader change. I am not proposing runtime restoration blocks or SQL-loader changes.