Feedback-ID: i0c21471d:Fastmail
MIME-Version: 1.0
Date: Mon, 06 Apr 2026 14:09:55 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "Jelte Fennema" <postgres@jeltef.nl>,
 "Andrew Dunstan" <andrew@dunslane.net>
Cc: "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>
Message-Id: <6ecd7573-850d-424a-9794-3ee1f73851c0@app.fastmail.com>
In-Reply-To: <DHM6C7SLS4BN.1WW9Z4PRPN0VJ@jeltef.nl>
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>
Subject: Re: pg_get__*_ddl consolidation
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/6ecd7573-850d-424a-9794-3ee1f73851c0%40app.fastmail.com>
Precedence: bulk

On Mon, Apr 6, 2026, at 12:24 PM, Jelte Fennema-Nio wrote:
> The thing I'm questioning is whether we need a new way of providing
> key+value pairs as optional arguments to functions. IMO we already had a
> perfectly fine one. Introducing another adds complexity (both to the
> code and to the user) and I don't see any compelling reason to do so.
>

I did the same question when reviewing one of these patches. My first reaction
was if we want flexibility to cover various use cases and maintainability to
add/deprecate new options, we need a mechanism to avoid breaking compatibility
or even overloading the function (complexity). My natural choice was key-value
pair arguments. It needs new support code (although we already use this style
in some of the backend functions -- e.g. pg_logical_slot_*_changes()).

> Attached is a patch with roughly what I have in mind instead. By doing
> this we can also make the functinos STRICT, so that we don't have to
> worry about handling NULL values for the first argument.
>

That's a good point.

> Afaict this named parameter approach only has benefits over the VARIADIC
> argument one. But if I'm wrong about that, please let me know.
>

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. You also need to create another
function with a different list of arguments to support a new option. If we are
fine with this restriction, your proposal seems ok to me.

One point in favor of your proposal is that the named arguments seems more
intuitive than the key-value pair arguments. The first impression is that
interchanging key and value is harder to figure out that the named argument
notation. Of course, documentation and some examples can help the user to write
these function calls. That's not the first function that uses this key-value
argument approach.


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/