Re: pg_get__*_ddl consolidation

Jelte Fennema <postgres@jeltef.nl>

From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Euler Taveira <euler@eulerto.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, "David G. Johnston" <david.g.johnston@gmail.com>, japin <japinli@hotmail.com>, Zsolt Parragi <zsolt.parragi@percona.com>, Álvaro Herrera <alvherre@kurilemu.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-24T19:48:20Z
Lists: pgsql-hackers
On Tue, 7 Apr 2026 at 14:36, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> So to summarize (from my biased viewpoint) I think the downsides are:
> 1. Uncommon calling convention: only pg_restore_*_stats and
>    pg_logical_slot_*_changes use it, while all other functions support
>    named parameters.
> 2. Needs custom option parsing logic
> 3. More characters to type because you have to quote booleans, integers
>    and argument names.
> 4. Requires functions to be marked as NOSTRICT, which then needs
>    additional NULL handling
> 5. It can be unclear to a reader of a query that the function arguments
>    should be interpreted as key-value pair
> 6. Breaks auto formatting
>
> And the benefit:
> 1. Forces people to specify the argument name
>
> I don't think those benefits outweigh the downsides.

I'm not sure how I can explain my argument better. I think it'd be sad
if we standardized these pg_get_ddl_* functions to use this suboptimal
calling convention.



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Use named boolean parameters for pg_get_*_ddl option arguments

  2. Convert ddlutils regression tests to TAP tests.

  3. Fix pfree crash in pg_get_role_ddl() and pg_get_database_ddl().

  4. Fixups for a4f774cf1c7

  5. Add infrastructure for pg_get_*_ddl functions

  6. Add pg_get_database_ddl() function

  7. Add pg_get_role_ddl() function

  8. Add pg_get_tablespace_ddl() function