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

From Chapman Flack
Subject Re: ArchiveEntry optional arguments refactoring
Date
Msg-id 9dd3701a-cc56-d2ba-3f3a-95b493b6a92b@anastigmatix.net
Whole thread Raw
In response to Re: ArchiveEntry optional arguments refactoring  (Andres Freund <andres@anarazel.de>)
Responses Re: ArchiveEntry optional arguments refactoring  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

Regards,
-Chap


pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Referential Integrity Checks with Statement-level Triggers
Next
From: Andres Freund
Date:
Subject: Re: ArchiveEntry optional arguments refactoring