Fixed the issue above. The v5 patch is ready for review/testing.
One thing I noticed, though I'm not sure if it's the point here, is that it's not possible to extract only the foreign keys or only the triggers from the table. So if we want to extract the objects independently by type, we would need to have all the return types as optional, and we could have more granularity in the return types.
Just like you have...
if (!ctx->include_indexes)
You could have too
+ if (!ctx->include_create_table)
+ if (!ctx->include_foreign_keys)
+ if (!ctx->include_primary_keys)
Because only in this way can we more or less execute the dump behavior here, which is to create all the tables beforehand, then primary keys, then foreign keys, then triggers.
I repeat, sorry if this is not the function's intended purpose.
I don't think per-contype flags are the right shape, though. The existing toggles group by catalog (indexes, constraints, rules, ...); splitting constraints into PK/FK/CHECK/UNIQUE/EXCLUDE/NOT NULL adds six flags on a second axis, and the function already carries nine. Only FKs have the cross-table dependency-ordering problem; the rest only reference the same table, so splitting them unlocks nothing new.
On include_create_table, we are reconstructing the DDL for the table itself, so I don't think we should skip the CREATE TABLE statement. I'd rather always emit CREATE TABLE.
