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

From Andres Freund
Subject Re: ArchiveEntry optional arguments refactoring
Date
Msg-id 20190123173613.7jgxkiwxa5zzm2ww@alap3.anarazel.de
Whole thread Raw
In response to Re: ArchiveEntry optional arguments refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ArchiveEntry optional arguments refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2019-01-23 12:32:06 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-01-23 13:58:07 -0300, Alvaro Herrera wrote:
> >> It does.  How does pgindent behave with it?
> 
> > It craps out:
> > Error@3649: Unbalanced parens
> > Warning@3657: Extra )
> 
> > But that can be worked around with something like
> 
> >         te = ArchiveEntry(fout, tdinfo->dobj.catId, tdinfo->dobj.dumpId,
> >                           ARCHIVE_ARGS(.tag = tbinfo->dobj.name,
> >                                        .namespace = tbinfo->dobj.namespace->dobj.name,
> >                                        .owner = tbinfo->rolname,
> >                                        .desc = "TABLE DATA",
> >                                        .section = SECTION_DATA,
> >                                        .copyStmt = copyStmt,
> >                                        .deps = &(tbinfo->dobj.dumpId),
> >                                        .nDeps = 1,
> >                                        .dumpFn = dumpFn,
> >                                        .dumpArg = tdinfo,
> >                                        ));
> > which looks mildly simpler too.
> 
> That looks fairly reasonable from here, but I'd suggest
> ARCHIVE_OPTS rather than ARCHIVE_ARGS.

WFM. Seems quite possible that we'd grow a few more of these over time,
so establishing some common naming seems good.

Btw, do you have an opionion on keeping catId / dumpId outside/inside
the argument struct?


> Can we omit the initial dots if we use a wrapper macro?  Would it be
> a good idea to do so (I'm not really sure)?

Not easily, if at all, I think. We'd have to do a fair bit of weird
macro magic (and then still end up with limitations) to "process" each
argument individually.  And even if it were easy, I don't think it's
particularly advantageous.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ArchiveEntry optional arguments refactoring
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] REINDEX CONCURRENTLY 2.0