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
