Coverity complained about what you did in RelationParseRelOptions
in c95c25f9a:
*** CID 1595992: Null pointer dereferences (FORWARD_NULL)
/srv/coverity/git/pgsql-git/postgresql/src/backend/utils/cache/relcache.c: 499
in RelationParseRelOptions()
493
494 /*
495 * Fetch reloptions from tuple; have to use a hardwired
descriptor because
496 * we might not have any other for pg_class yet (consider
executing this
497 * code for pg_class itself)
498 */
>>> CID 1595992: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "tableam" to "extractRelOptions", which
>>> dereferences it.
499 options = extractRelOptions(tuple, GetPgClassDescriptor(),
500
tableam, amoptsfn);
501
I see that extractRelOptions only uses the tableam argument for some
relkinds, and RelationParseRelOptions does set it up for those
relkinds --- but Coverity's complaint isn't without merit, because
those two switch statements are looking at *different copies of the
relkind*, which in theory could be different. This all seems quite
messy and poorly factored. Can't we do better? Why do we need to
involve two copies of allegedly the same pg_class tuple, anyhow?
regards, tom lane
