pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: jian he <jian.universality@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump does not dump domain not-null constraint's comments
Date: Fri, 12 Sep 2025 19:02:33 -0700
Message-ID: <20250913020233.fa.nmisch@google.com> (raw)
In-Reply-To: <202507151340.d4jyrbdae5af@alvherre.pgsql>
References: <CACJufxHg-KABN2FyKgY4bBM=pa0ijpwarKyCA0F+0Dqb_TjjCA@mail.gmail.com>
	<202507151340.d4jyrbdae5af@alvherre.pgsql>

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.





view thread (16+ messages)  latest in thread

Message-ID: <20250913020233.fa.nmisch@google.com>
Permalink:  ../20250913020233.fa.nmisch@google.com/
Also on:    postgresql.org/message-id/20250913020233.fa.nmisch@google.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: noah@leadboat.com, alvherre@kurilemu.de, jian.universality@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: pg_dump does not dump domain not-null constraint's comments
  In-Reply-To: <20250913020233.fa.nmisch@google.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox