Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases

Álvaro Herrera <alvherre@kurilemu.de>

From: Álvaro Herrera <alvherre@kurilemu.de>
To: Andrew Bille <andrewbille@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, David Rowley <dgrowleyml@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-10-18T12:06:56Z
Lists: pgsql-bugs

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 determination of not-null constraint "locality" for inherited columns

  2. Fix pg_dump sorting of foreign key constraints

  3. Sort dump objects independent of OIDs, for the 7 holdout object types.

  4. Add pg_constraint rows for not-null constraints

By the way, while testing this, I ran into a pg_dump bug.  In the object
sorting algorithm (DOTypeNameCompare), we fail to process objects of
type DO_FK_CONSTRAINT correctly (which is to say: identically to
DO_CONSTRAINT ones), so we fall back to compare by OID, and in debug
builds, the assertion at the bottom of the routine fires.  The fix is
trivial:

diff --git a/src/bin/pg_dump/pg_dump_sort.c b/src/bin/pg_dump/pg_dump_sort.c
index a51064f21e3..0aec83bedb2 100644
--- a/src/bin/pg_dump/pg_dump_sort.c
+++ b/src/bin/pg_dump/pg_dump_sort.c
@@ -328,7 +328,8 @@ DOTypeNameCompare(const void *p1, const void *p2)
 		if (cmpval != 0)
 			return cmpval;
 	}
-	else if (obj1->objType == DO_CONSTRAINT)
+	else if (obj1->objType == DO_CONSTRAINT ||
+			 obj1->objType == DO_FK_CONSTRAINT)
 	{
 		ConstraintInfo *robj1 = *(ConstraintInfo *const *) p1;
 		ConstraintInfo *robj2 = *(ConstraintInfo *const *) p2;


I'll apply this separately, because it goes back to 13 (commit
0decd5e89db9).

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Computing is too important to be left to men." (Karen Spärck Jones)