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)