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

From Chapman Flack
Subject Re: ArchiveEntry optional arguments refactoring
Date
Msg-id 4a4d10a2-bffc-ed13-65a4-5fe762175eea@anastigmatix.net
Whole thread Raw
In response to Re: ArchiveEntry optional arguments refactoring  (Dmitry Dolgov <9erthalion6@gmail.com>)
Responses Re: ArchiveEntry optional arguments refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: ArchiveEntry optional arguments refactoring  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 1/23/19 10:12 AM, Dmitry Dolgov wrote:
> To make this discussion a bit more specific, I've created a patch of how
> it can look like.
A little bit of vararg-macro action can make such a design look
even tidier, cf. [1].

Or are compilers without vararg macros still in the supported mix?

-Chap



[1] https://github.com/NetBSD/src/blob/trunk/sys/sys/midiio.h#L709

The macros in [1] are not defined to create a function call, but only
the argument structure because there might be several functions to pass
it to, so a call would be written like func(&SEQ_MK_CHN(NOTEON, ...)).

In ArchiveEntry's case, if there's only one function involved, there'd
be no reason not to have a macro produce the whole call.


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ArchiveEntry optional arguments refactoring
Next
From: Tom Lane
Date:
Subject: Re: ArchiveEntry optional arguments refactoring