Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Tab completion for ALTER DATABASE … SET TABLESPACE |
Дата | |
Msg-id | 20180921055201.3qwuv2ojhsxzt56u@alap3.anarazel.de обсуждение исходный текст |
Ответ на | 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 2018-09-20 16:19:26 -0700, Andres Freund wrote: > On 2018-09-20 19:03:16 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > On 2018-09-20 18:38:36 -0400, Tom Lane wrote: > > >> hmmm ... but even with variadic, C's macro facility is so weak that > > >> I'm not sure we can reimplement these with it. What would the > > >> expansion look like? > > > > > There's a dirty hack to count arguments in vararg macros: > > > https://groups.google.com/d/msg/comp.std.c/d-6Mj5Lko_s/5fW1bP6T3RIJ > > > > Doesn't seem to help for this case. What we really want is to expand > > a given pattern once for each variadic argument, and I don't see how > > to get there from here. > > Depends on whether your goal is to simplify *using* the macro, or the > infrastructure for the macro. Afaict it should be relatively > straightforward to use a, possibly simplified, macro like referenced > above to have TailMatches(...), TailMatchesCS(...), Matches(...) that > then expand to the current *N macros. > > > > Although maybe I'm thinking too much inside-the-box. The expansion > > doesn't necessarily have to be identical to the code the macros > > generate today. In fact, that code is kinda bulky. I wonder if > > we could go over to something involving a variadic function, or > > maybe an array of string-pointer constants? > > Yea, that might be a way to simplify both the macros and the use of the > macros. Assuming we have something like PP_NARG, ISTM it should be > relatively straightforward to define something like > > #define Matches(...) CheckMatchesFor(PP_NARG(__VA_ARGS__), __VA_ARGS__) > > and then have a CheckMatchesFor() first check previous_words_count, and > then just have a simple for loop through previous_words[] - afaict the > number of arguments ought to suffice to make that possible? Here's a very quick-and-dirty implementation of this approach. Some very very brief testing seems to indicate it works, although I'm sure not perfectly. The current duplication of the new functions doing the actual checking (like CheckMatchesFor(), CheckTailMatchesFor()) would probably need to be reduced. But I don't want to invest actual time before we decide that this could be something we'd actually want to pursue. Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: