Date: Thu, 17 Jan 2019 12:02:16 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: ArchiveEntry optional arguments refactoring
Message-ID: <201901171502.nh6krqterjdd@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+q6zcXRxPE+qp6oerQWJ3zS061WPOhdxeMrdc-Yf-2V5vsrEw@mail.gmail.com>
User-Agent: NeoMutt/20180716-1013-2c1e88
Precedence: bulk

On 2019-Jan-16, Dmitry Dolgov wrote:


> Proposed idea is to refactor out all/optional arguments into a separate data
> structure, so that adding/removing a new argument wouldn't change that much of
> unrelated code. Then for every invocation of ArchiveEntry this structure needs
> to be prepared before the call, or as Andres suggested:
> 
>     ArchiveEntry((ArchiveArgs){.tablespace = 3,
>                                .dumpFn = somefunc,
>                                ...});

Prepping the struct before the call would be our natural style, I think.
This one where the struct is embedded in the function call does not look
*too* horrible, but I'm curious as to what does pgindent do with it.

> Another suggestion from Amit is to have an ArchiveEntry() function with limited
> number of parameters, and an ArchiveEntryEx() with those extra parameters which
> are not needed in usual cases.

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.  But maybe we can combine both ideas and have one "normal"
function with only the most common args, and create ArchiveEntryExtended
to use the struct as proposed by Andres.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services