Re: ArchiveEntry optional arguments refactoring

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Chapman Flack <chap@anastigmatix.net>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Amit Khandekar <amitdkhan.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-23T17:25:09Z
Lists: 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


Commits

  1. Add ArchiveOpts to pass options to ArchiveEntry

  2. Remove WITH OIDS support, change oid catalog column visibility.