On Mon, Jun 22, 2026 at 8:25 PM Marcos Pegoraro <[email protected]> wrote:
> Em seg., 22 de jun. de 2026 às 03:27, Akshay Joshi < > [email protected]> escreveu: > >> 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. regards > Marcos > >
