Re: ArchiveEntry optional arguments refactoring

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ArchiveEntry optional arguments refactoring
Date: 2019-01-17 15:02:16
Message-ID: 201901171502.nh6krqterjdd@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-01-17 15:05:50 Re: Acceptable/Best formatting of callbacks (for pluggable storage)
Previous Message Arthur Zakirov 2019-01-17 14:15:07 Re: [PROPOSAL] Shared Ispell dictionaries