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

On Thu, Jun 11, 2026 at 6:38 PM Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:

> Em qui., 11 de jun. de 2026 às 04:48, Akshay Joshi <
> akshay(dot)joshi(at)enterprisedb(dot)com> escreveu:
>
>> 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.

> regards
> Marcos
>
>