Feedback-ID: ie3de48e3:Fastmail
Date: Sat, 13 Sep 2025 13:59:29 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Noah Misch <noah@leadboat.com>
Cc: jian he <jian.universality@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump does not dump domain not-null constraint's comments
Message-ID: <202509131159.p74ngjfov4l6@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20250913020233.fa.nmisch@google.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202509131159.p74ngjfov4l6%40alvherre.pgsql>
Precedence: bulk

On 2025-Sep-12, Noah Misch wrote:

> 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.

Sounds sane.

> In the absence of objections, I'll make it so.

Please do, thanks.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/