| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
| 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 17:10:12 |
| Message-ID: | 20190123171012.zrr7kfqy4jddhe7m@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2019-01-23 12:05:10 -0500, Chapman Flack wrote:
> 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].
> [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.
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.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2019-01-23 17:16:14 | Re: Referential Integrity Checks with Statement-level Triggers |
| Previous Message | Andres Freund | 2019-01-23 17:07:01 | Re: ArchiveEntry optional arguments refactoring |