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

Álvaro Herrera <alvherre@kurilemu.de>

From: Álvaro Herrera <alvherre@kurilemu.de>
To: jian he <jian.universality@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-07T09:25:53Z
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 →
  1. Fix pg_dump COMMENT dependency for separate domain constraints.

  2. pg_dump: include comments on not-null constraints on domains, too

  3. Fix dumping of comments on invalid constraints on domains

  4. Catalog domain not-null constraints

  5. In pg_dump, don't dump a stats object unless dumping underlying table.

  6. Enable CHECK constraints to be declared NOT VALID

On 2025-May-07, jian he wrote:

> in PG17 and master, pg_dump (--schema=test --no-owner)
> [...]
> didn't produce
> COMMENT ON CONSTRAINT nn ON DOMAIN test.d1 IS 'not null constraint on
> domain d1';
> we should make pg_dump to produce it too?

Yes, this is clearly a pg17 bug whose fix should be backpatched.

> The attached patch tries to make it produce comments on not-null
> constraints on domains.

Thanks, I'll have a look.

> I aslo renamed struct TypeInfo fields, nDomChecks will be renamed to
> nDomConstrs; domChecks will be renamed to domConstrs.
> TypeInfo->domConstrs will also include not-null constraint
> information, changing from domChecks to domConstrs makes sense, IMHO.

Hmm, for a backpatch I would leave the field names alone since they are
publicly visible; we can rename separately in pg19 once it opens.  Can
you resubmit splitting the renaming out to a 0002 patch?

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle."  (Larry Wall, Apocalypse 6)