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

On Thu, Jul 2, 2026 at 7:47 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com>
wrote:

> Hello,
>
> Looking at this, one thing that concerns me is the large amount of
> overlap with dumpTableSchema() in pg_dump.
>
> I wonder if it would make sense to separate the SQL generation logic
> into frontend/backend-shared code so that it could also be used by
> pg_dump. The catalog lookup would naturally remain separate, but
> sharing the DDL generation itself would significantly reduce the
> duplication.
>

Thanks for the suggestion. The overlap is real, but sharing the SQL
generation logic at the C level runs into a few structural mismatches:
dumpTableSchema drives column rendering off pre-populated TableInfo arrays
that pg_dump bulk-loaded at startup, while the backend function uses live
syscache lookups - a shared builder would need an adapter layer roughly as
large as the code it replaces. The pattern PostgreSQL already uses for this
kind of sharing is to call backend pg_get_*def functions via SQL from
pg_dump — it already does this 20 times for indexes, constraints, triggers,
rules, and statistics. The natural long-term path would be for pg_dump to
call pg_get_table_ddl() the same way and retire dumpTableSchema, but that
is a substantial refactor in its own right and feels out of scope here.

By the way, a couple of comments use a Unicode RIGHTWARDS ARROW
> (U+2192). Please use an ASCII equivalent instead.
>

   Will fix it in the next v15 patch.

>
> Regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>