On Thu, Jul 2, 2026 at 7:47 AM Kyotaro Horiguchi <[email protected]> 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 >
