Re: ArchiveEntry optional arguments refactoring

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ArchiveEntry optional arguments refactoring
Date: 2019-01-23 18:36:36
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 1/23/19 12:25 PM, Andres Freund wrote:
> On 2019-01-23 12:22:23 -0500, Chapman Flack wrote:

>> ArchiveEntry(fout, dbCatId, dbDumpId, .tag = datname, .owner = dba,
>> .desc = "DATABASE", .section = SECTION_PRE_DATA,
>> .defn = creaQry->data, .dropStmt = delQry->data);

> IDK, it'd be harder to parse correctly as a C programmer though. ...
> weirdly mixing struct arguments and normal function arguments seems
> quite confusing.

Hmm, I guess the rubric I think with goes something like "is a C
programmer who encounters this in a source file for the first time
likely to guess wrong about what it means?", and in the case above,
I can scarcely imagine it.

ISTM that these days, many people are familiar with several languages
that allow a few mandatory, positional parameters followed by optional
named ones, and so a likely reaction would be "hey look, somebody used
a macro here to make C look more like <insert other language I know>."

On 1/23/19 12:32 PM, Tom Lane wrote:
> Can we omit the initial dots if we use a wrapper macro?

That, I think, is hard.

Getting to the form above is downright easy; making the dots go away,
even if achievable, seems way further down the path of diminishing


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-01-23 18:59:55 Re: Non-deterministic IndexTuple toast compression from index_form_tuple() + amcheck false positives
Previous Message Andres Freund 2019-01-23 18:33:21 Re: [HACKERS] REINDEX CONCURRENTLY 2.0