From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Dmitry Dolgov <9erthalion6@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: ArchiveEntry optional arguments refactoring
In-reply-to: <201901171502.nh6krqterjdd@alvherre.pgsql>
References: <201901171502.nh6krqterjdd@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 17 Jan 2019 12:02:16 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13280.1547738619.1@sss.pgh.pa.us>
Date: Thu, 17 Jan 2019 10:23:39 -0500
Message-ID: <13281.1547738619@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jan-16, Dmitry Dolgov wrote:
>> ArchiveEntry((ArchiveArgs){.tablespace = 3,
>> .dumpFn = somefunc,
>> ...});

> Is there real savings to be had by doing this?  What would be the
> arguments to each function?  Off-hand, I'm not liking this idea too
> much.

I'm not either.  What this looks like it will mainly do is create
a back-patching barrier, with little if any readability improvement.

I don't buy the argument that this would move the goalposts in terms
of how much work it is to add a new argument.  You'd still end up
touching every call site.

			regards, tom lane