From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, a(dot)zakirov(at)postgrespro(dot)ru, ilmari(at)ilmari(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE |
Date: | 2018-09-21 21:46:48 |
Message-ID: | 20180921214648.6mpuryao6qrcm26d@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-09-22 09:15:27 +1200, Thomas Munro wrote:
> On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think there's some argument to be made about the "mental" complexity
> > of the macros - if we went for them, we'd certainly need to add some
> > docs about how they work. One argument for having PP_NARGS (renamed) is
> > that it doesn't seem useful just here, but in a few other cases as well.
>
> It's a nice general facility to have in the tree. It seems to compile
> OK on clang, gcc, MSVC (I added this thread as CF entry 20/1798 as a
> lazy way to see if AppVeyor would build it OK, and it worked fine
> until conflicting commits landed). I wonder if xlc, icc, aCC and Sun
> Studio can grok it.
I think unless $compiler doesn't correctly implement vararg macros, it
really should just work. There's nothing but pretty smart use of
actually pretty plain vararg macros. If any of the other compilers have
troubles with that, they'd really not implement vararg macros...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-09-21 21:56:00 | Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE |
Previous Message | Jeremy Finzel | 2018-09-21 21:33:38 | Re: Proposal for disk quota feature |