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.
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.
