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 →
-
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 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)