Re: ArchiveEntry optional arguments refactoring - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ArchiveEntry optional arguments refactoring
Date
Msg-id 20190123172509.q6lh4rytksfrcj3e@alap3.anarazel.de
Whole thread Raw
In response to Re: ArchiveEntry optional arguments refactoring  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: ArchiveEntry optional arguments refactoring  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On 2019-01-23 12:22:23 -0500, Chapman Flack wrote:
> On 1/23/19 12:10 PM, Andres Freund wrote:
> > On 2019-01-23 12:05:10 -0500, Chapman Flack wrote:
> >> [1] https://github.com/NetBSD/src/blob/trunk/sys/sys/midiio.h#L709
> 
> > I'm not really seeing this being more than obfuscation in this case. The
> > only point of the macro is to set the .tag and .op elements to something
> > without adding redundancies due to the struct name. Which we'd not have.
> 
> Granted, that example is more elaborate than this case, but writing
> 
> 
> ArchiveEntry(fout, dbCatId, dbDumpId, .tag = datname, .owner = dba,
>              .desc = "DATABASE", .section = SECTION_PRE_DATA,
>              .defn = creaQry->data, .dropStmt = delQry->data);
> 
> instead of
> 
> ArchiveEntry(fout, dbCatId, dbDumpId, &(ArchiveOpts){.tag = datname,
>              .owner = dba, .desc = "DATABASE",
>              .section = SECTION_PRE_DATA, .defn = creaQry->data,
>              .dropStmt = delQry->data});
> 
> would be easy, and still save a bit of visual noise.

IDK, it'd be harder to parse correctly as a C programmer though. I'm up
with a wrapper macro like
#define ARCHIVE_ARGS(...) &(ArchiveOpts){__VA_ARGS__}
but weirdly mixing struct arguments and normal function arguments seems
quite confusing.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: ArchiveEntry optional arguments refactoring
Next
From: Tom Lane
Date:
Subject: Re: ArchiveEntry optional arguments refactoring