Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements

On Mon, Jun 22, 2026 at 8:25 PM Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:

> Em seg., 22 de jun. de 2026 às 03:27, Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> 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
>
>