The documentation paragraph for `includes_foreign_keys` now directs users to `only_foreign_keys` as the intended second pass. Regression coverage adds three cases: the FK-only emission for your cons example, the zero-row result for a table without FKs, and the error path.
I still think this model of only having options for foreign keys is incomplete, maybe wrong.
Imagine then cloning a schema from a publication server to be executed on a subscription server. So I don't want any other constraints besides the primary key, for example. The way you implemented it is not possible.
Furthermore
having only_foreign_keys and includes_foreign_keys seems confuse.
OK. I'd like to change the model, not just the flag names. Drop the entire includes_* family and only_foreign_keys, replace them with two mutually-exclusive variadic keys:
- include => 'kind1,kind2,...' — emit only these kinds
- exclude => 'kind1,kind2,...' — emit everything except these
Setting both is an error. Setting neither emits everything (today's default behavior, which is preserved).
Vocabulary: indexes, primary_key, unique, check, foreign_keys, exclusion, rules, statistics, triggers, policies, rls, replica_identity, partitions. Unknown kind → parse-time error, which also
catches typos that the boolean version silently accepted.
If everyone approves the model above, I'll try implementing it.
