Re: Making tab-complete.c easier to maintain

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Making tab-complete.c easier to maintain
Дата
Msg-id CAB7nPqR7fFso=2iBz08K1BD10jOcd2OcvA-8g9TSWVmR7YEXsg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Making tab-complete.c easier to maintain  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Making tab-complete.c easier to maintain  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Dec 17, 2015 at 6:04 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, Dec 17, 2015 at 7:24 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> Kyotaro's suggestion of using a macro NEG x to avoid complicating the
> string constants seems good to me.  But perhaps like this?
>
>   TailMatches4("COMMENT", "ON", MatchAny, MatchAnyExcept("IS"))
>
> See attached patch which does it that way.

Fine for me.

>>> Addition to that, I feel that successive "MatchAny"s are a bit
>>> bothersome.
>>>
>>>>  TailMatches6("COMMENT", "ON", MatchAny, MatchAny, MatchAny, MatchAny)) &&
>>>>              !TailMatches1("IS")
>>>
>>> Is MachAny<n> acceptable? On concern is the two n's
>>> (TailMatches<n> and MatchAny<n>) looks a bit confising.
>>>
>>>>  TailMatches4("COMMENT", "ON", MatchAny3, "!IS")
>>
>> Ah, OK, so you would want to be able to have an inner list, MatchAnyN
>> meaning actually a list of MatchAny items repeated N times. I am not
>> sure if that's worth it.. I would just keep it simple, and we are just
>> discussing about a couple of places only that would benefit from that.
>
> +1 for simple.

+#define CompleteWithList10(s1, s2, s3, s4, s5, s6, s7, s8, s9, s10)    \
+do { \
+       static const char *const list[] = { s1, s2, s3, s4, s5, s6,
s7, s8, s9, s10, NULL }; \
+       completion_charpp = list; \
+       completion_case_sensitive = false; \
+       matches = completion_matches(text, complete_from_list); \
+} while (0)
Actually we are not using this one. I am fine if this is kept, just
worth noting.

OK, I am marking that as ready for committer. Let's see what happens next.
Regards,
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Refactoring speculative insertion with unique indexes a little
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Refactoring speculative insertion with unique indexes a little