Re: pg_dump does not dump domain not-null constraint's comments
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-13T02:02:33Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix pg_dump COMMENT dependency for separate domain constraints.
- a685c057ad4c 13.23 landed
- 85d6ed31fc7c 14.20 landed
- 0773f3a875f1 15.15 landed
- e127764b65da 17.7 landed
- 4ad846445dd0 18.0 landed
- 3cf328eca84a 16.11 landed
- c044b50d199c 19 (unreleased) landed
-
pg_dump: include comments on not-null constraints on domains, too
- f9545e95c5e7 18.0 landed
- da71717f0a7c 19 (unreleased) landed
- 6b755d8d70b2 17.6 landed
-
Fix dumping of comments on invalid constraints on domains
- e04aca1c4d33 14.19 landed
- dca0e9693b71 18.0 landed
- d07bc7c2b3ca 17.6 landed
- cef998ef8314 16.10 landed
- 5a261c135d43 15.14 landed
- 57949cea5af0 13.22 landed
- 0858f0f96ebb 19 (unreleased) landed
-
Catalog domain not-null constraints
- e5da0fe3c22b 17.0 cited
-
In pg_dump, don't dump a stats object unless dumping underlying table.
- 7418767f11d1 17.0 cited
-
Enable CHECK constraints to be declared NOT VALID
- 897795240cfa 9.2.0 cited
On Tue, Jul 15, 2025 at 03:40:38PM +0200, Álvaro Herrera wrote:
> On 2025-Jul-15, jian he wrote:
> > we should let:
> > dumpConstraint handles dumping separate "NOT VALID" domain constraints along
> > with their comments.
> > dumpDomain: handles dumping "inlined" valid (not separate) domain constraints
> > together with their comments.
This became commit 0858f0f.
> @@ -18487,8 +18493,25 @@ dumpConstraint(Archive *fout, const ConstraintInfo *coninfo)
> .description = "CHECK CONSTRAINT",
> .section = SECTION_POST_DATA,
> .createStmt = q->data,
> .dropStmt = delq->data));
> +
> + if (coninfo->dobj.dump & DUMP_COMPONENT_COMMENT)
> + {
> + char *qtypname;
> +
> + PQExpBuffer conprefix = createPQExpBuffer();
> + qtypname = pg_strdup(fmtId(tyinfo->dobj.name));
> +
> + appendPQExpBuffer(conprefix, "CONSTRAINT %s ON DOMAIN",
> + fmtId(coninfo->dobj.name));
> +
> + dumpComment(fout, conprefix->data, qtypname,
> + tyinfo->dobj.namespace->dobj.name,
> + tyinfo->rolname,
> + coninfo->dobj.catId, 0, tyinfo->dobj.dumpId);
The last argument gives the dump object on which the comment has a dependency.
Since this is the case of a separately-dumped constraint, the comment needs to
depend on that constraint (coninfo), not on the domain (tyinfo):
- coninfo->dobj.catId, 0, tyinfo->dobj.dumpId);
+ coninfo->dobj.catId, 0, coninfo->dobj.dumpId);
I didn't encounter a failure from this, but sufficient restore parallelism
might reach a failure. A failure would look like a "does not exist" error in
the COMMENT command, due to the constraint not yet existing.
dumpTableConstraintComment() is an older case that optimally handles the last
dumpComment() arg.
In the absence of objections, I'll make it so.