public inbox for [email protected]  

help / color / mirror / Atom feed

From: Euler Taveira <[email protected]>
To: Jelte Fennema <[email protected]>
To: Andrew Dunstan <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: japin <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: pg_get__*_ddl consolidation
Date: Mon, 06 Apr 2026 14:09:55 -0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAN4CZFNYM5jNA_gLu9miAXg_7c8Z2zf-ePc+0rzidAV3CBs=cw@mail.gmail.com>
	<[email protected]>
	<SY7PR01MB10921A6E1E08A48F3426FE529B651A@SY7PR01MB10921.ausprd01.prod.outlook.com>
	<CAKFQuwYcppypeGBwa7ZbDAfoUXSv+kLhJuAXsdwBmKrvy8wDFw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAGECzQRyh9Yf87sMgBaYjaas7yx5R91ga5JjJxAx3W_Uu8BfUA@mail.gmail.com>
	<[email protected]>
	<[email protected]>

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/

view thread (31+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pg_get__*_ddl consolidation
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox