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

All,

A quick note on a design change I made in the *pg_get_table_ddl* option
surface.

The earlier draft exposed one boolean option per sub-object kind:
include_indexes, include_primary_key, include_check, include_foreign_keys,
include_rules, include_statistics, include_rls, include_replica_identity,
include_partitions, and so on. Every new kind we wanted to gate (triggers,
policies, exclusion constraints…) meant another option name. Callers
wanting "everything except FKs" had to flip nine flags, and the
include/exclude polarity was not symmetric: to drop one item, you toggled
one flag, but to keep only one item, you toggled all the others.

*I have replaced those with two options:*
- include — comma-separated list of kinds; emit only the listed ones.
- exclude — comma-separated list of kinds; emit everything except the
listed ones.

*Vocabulary*: table, indexes, primary_key, unique, check, foreign_keys,
exclusion, rules, statistics, triggers, policies, rls, replica_identity,
partitions.
NOT NULL is intentionally omitted from the vocabulary; it's always emitted
to avoid silently producing schemas that accept NULLs when the source would
have rejected them.

The v10 patch is ready for review.

On Tue, Jun 23, 2026 at 2:52 PM Akshay Joshi <akshay(dot)joshi(at)enterprisedb(dot)com>
wrote:

>
>
> On Tue, Jun 23, 2026 at 12:51 PM Kyotaro Horiguchi <
> horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
>> At Mon, 22 Jun 2026 18:10:53 +0530, Akshay Joshi <
>> akshay(dot)joshi(at)enterprisedb(dot)com> wrote in
>> > The v9 patch is ready for review.
>>
>> I have not looked closely at the DDL generation logic itself, but I
>> have a few comments on how pg_get_table_ddl handles its options.
>>
>> Since pg_get_table_ddl_internal() appears to copy these values into
>> TableDdlContext almost immediately, I wonder whether TableDdlContext
>> could be initialized by the caller instead.
>>
>> Using positional boolean arguments is probably fine when there are
>> only a handful of options, but with around fifteen of them the current
>> approach seems somewhat error-prone.
>>
>> It might also be clearer to initialize the default values first, and
>> then override only the fields corresponding to explicitly specified
>> options, rather than folding the default handling and option lookup
>> into the same expression.
>>
>
> I assume that changing the implementation model, as I mentioned in my
> other email, will solve this problem as well. We can drop the entire
> includes_* family and only_foreign_keys, and replace them with two mutually
> exclusive variadic keys:
> include => 'kind1,kind2,...' — emit only these kinds
> exclude => 'kind1,kind2,...' — emit everything except these kinds
>>
>>
>> Regards,
>>
>> --
>> Kyotaro Horiguchi
>> NTT Open Source Software Center
>>
>