Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements
Akshay Joshi <akshay.joshi@enterprisedb.com>
From: Akshay Joshi <akshay.joshi@enterprisedb.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: li.evan.chao@gmail.com, zsolt.parragi@percona.com, pgsql-hackers@lists.postgresql.org
Date: 2026-06-23T09:22:37Z
Lists: pgsql-hackers
On Tue, Jun 23, 2026 at 12:51 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > At Mon, 22 Jun 2026 18:10:53 +0530, Akshay Joshi < > akshay.joshi@enterprisedb.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 >