From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | andres(at)anarazel(dot)de |
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:15:27 |
Message-ID: | CAEepm=3dWTKt9q3aqgj_wNjtenyyFW7RGVHW_5Qf3LzGYATQ+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Finzel | 2018-09-21 21:33:38 | Re: Proposal for disk quota feature |
Previous Message | Andres Freund | 2018-09-21 20:58:27 | Re: Strange failure in LWLock on skink in REL9_5_STABLE |