Re: pg_dump does not dump domain not-null constraint's comments

On 2025-May-22, jian he wrote:

> I actually found another bug.
> create schema test;
> CREATE DOMAIN test.d1 AS integer NOT NULL default 11;
> pg_dump --schema=test > 1.sql
> ""
> pg_dump: warning: could not resolve dependency loop among these items:
> pg_dump: detail: TYPE d1 (ID 1415 OID 18007)
> pg_dump: detail: CONSTRAINT d1_not_null (ID 1416 OID 18008)
> ""

Oh, interesting. I agree with the rough fix, but I think it's better if
we keep the contype comparisons rather than removing them, relaxing to
allow for one more char.

I didn't like the idea of stashing the not-null constraint in the same
array as the check constraints; it feels a bit dirty (especially because
of the need to scan the array in order to find the not-null one). I
opted to add a separate TypeInfo->notnull pointer instead. This feels
more natural. This works because we know a domain has only one not-null
constraint. Note that this means we don't need your proposed 0002
anymore.

I wonder to what extent we promise ABI compatibility of pg_dump.h
structs in stable branches. If that's an issue, we could easily use
your original patch for 17, and use the TypeInfo->notnull addition only
in 18, but I'm starting to lean on not bothering (i.e., use the same
patch in all branches). Compare commit 7418767f1 which was backpatched
all the way and modified struct StatsExtInfo; I don't think we got any
complaints.

I also modified the Perl test so that the COMMENT ON CONSTRAINT
statement is checked in a separate stanza. This works fine: the comment
is created in the create_sql of one stanza (the same where you had it),
then checked in the 'regexp' entry of another. I opted to move the
regexp for both constraints out of the main one.

The attached applies on top of your patch. Opinions?

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/