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

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)