Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE
От | Thomas Munro |
---|---|
Тема | Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE |
Дата | |
Msg-id | CAEepm=1HgXCXvevddrB0vHsK2MpkND0-+7xRVGh4WvE79oM2fg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE
|
Список | pgsql-hackers |
On Sat, Sep 22, 2018 at 9:46 AM Andres Freund <andres@anarazel.de> wrote: > On 2018-09-22 09:15:27 +1200, Thomas Munro wrote: > > On Sat, Sep 22, 2018 at 8:51 AM Andres Freund <andres@anarazel.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... I vote for doing it this way then. It may turn out to be useful for efficient SearchSysCache(...), DirectFunctionCall(...) and other things like that. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: