On Wed, Jul 1, 2026 at 8:41 PM Marcos Pegoraro <[email protected]> wrote:
> Em qua., 1 de jul. de 2026 às 11:12, Akshay Joshi < > [email protected]> escreveu: > >> pretty, owner, tablespace, and schema_qualified are plain boolean >> parameters with DEFAULT values >> *Filtering parameters:* *only_kinds* / *except_kinds* as text[] >> >>> If all parameters are optional, and all parameters are boolean, perhaps > you could also make pretty, owner, tablespace, and schema_qualified as > optional parts of only_kinds and except_kinds. > > Therefore, we could call these two ways and the result would be the same. > pg_get_table_ddl('idxd'::regclass, owner => false, tablespace => false, > except_kinds > => '{primary_key}'); > pg_get_table_ddl('idxd'::regclass, except_kinds => '{primary_key, > tablespace,owner}'); > > Obviously this way you have to know if owner param is false or it exists > on except_kinds. > What do you think ? > *owner* is the one case where it could work, but to make it consistent with how owner behaves in pg_get_tablespace_ddl and pg_get_database_ddl, we should not add it. *tablespace* doesn't map to a kind at all. It controls the inline TABLESPACE clause within the CREATE TABLE statement body it's a sub-clause, not a separate statement. If we added tablespace as a kind, except_kinds => '{table,tablespace}' would be wrong (if you're skipping the table statement, there's no inline clause to suppress), and except_kinds => '{tablespace}' would imply skipping a standalone statement that doesn't exist. *pretty* and *schema_qualified* are rendering/formatting options, not statement filters. They affect how every statement is rendered — indentation, name qualification — not which statements are emitted. Putting them in except_kinds conflates two orthogonal axes: filtering (what to emit) and formatting (how to emit it). The current design intentionally keeps these separate: only_kinds/except_kinds for statement-level filtering, booleans for rendering and inline-clause control. Merging them would make except_kinds overloaded and harder to document clearly. > > regards > Marcos >
