MIME-Version: 1.0
References: <202603201311.yhtqmvektawm@alvherre.pgsql>
 <bf49721a-a56f-4bdc-ac48-5d4dc1d01805@dunslane.net>
 <8ec9b67d-939e-4b22-8d56-a5129f92d32d@app.fastmail.com>
 <CAN4CZFNYM5jNA_gLu9miAXg_7c8Z2zf-ePc+0rzidAV3CBs=cw@mail.gmail.com>
 <555cdee4-c024-4872-9d96-82ef4216239c@dunslane.net>
 <SY7PR01MB10921A6E1E08A48F3426FE529B651A@SY7PR01MB10921.ausprd01.prod.outlook.com>
 <CAKFQuwYcppypeGBwa7ZbDAfoUXSv+kLhJuAXsdwBmKrvy8wDFw@mail.gmail.com>
 <a533fb1b-0f2c-4fc9-ab3b-6fb5ddac1800@dunslane.net>
 <a1c4dd3e-6694-4b7b-8432-f3b584735ff3@dunslane.net>
 <CAGECzQRyh9Yf87sMgBaYjaas7yx5R91ga5JjJxAx3W_Uu8BfUA@mail.gmail.com>
 <34dc4d59-fec8-43c2-aa7b-38917b3ce0aa@dunslane.net>
 <DHM6C7SLS4BN.1WW9Z4PRPN0VJ@jeltef.nl>
 <6ecd7573-850d-424a-9794-3ee1f73851c0@app.fastmail.com>
In-Reply-To: <6ecd7573-850d-424a-9794-3ee1f73851c0@app.fastmail.com>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Mon, 6 Apr 2026 22:24:32 +0200
Message-ID: 
 <CAGECzQTjKgAF1rRG446aP0yoAnXHP8-KrunZW_roZWj5H6Xxdw@mail.gmail.com>
Subject: Re: pg_get__*_ddl consolidation
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>,
	=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAGECzQTjKgAF1rRG446aP0yoAnXHP8-KrunZW_roZWj5H6Xxdw%40mail.gmail.com>
Precedence: bulk

On Mon, 6 Apr 2026 at 19:10, Euler Taveira <euler@eulerto.com> wrote:
> although we already use this style
> in some of the backend functions -- e.g. pg_logical_slot_*_changes()).

Thanks for the additional context. I didn't know about
pg_logical_slot_*_changes using this style. I searched the docs
locally and cannot find any other functions that use this style. I
think what makes pg_logical_slot_*_changes special, is that it passes
these options to the plugin. The plugin can define any valid options,
and postgres core cannot know what they are. I think this approach
makes sense for those functions because of that, but the ddl functions
don't pass the options to a plugin, so that argument does not apply
here.

> I also consider your approach but decided not to use it. The argument against
> named arguments is that you cannot add new argument *without* a DEFAULT value;
> if you do, all existing functions will fail.

I'm not sure what kind of change you're referring to here. I don't
understand how variadic options allow you to add a required argument
to an existing function without breaking existing callers. Could you
give a concrete example of a change that the VARIADIC allows, but the
named arguments don't?

> You also need to create another
> function with a different list of arguments to support a new option.

I don't understand this either. We often add new optional arguments to
existing functions in a new major release. e.g. pg_start_backup got
the exclusive argument in PG9.6. Or do you mean something else here?