Re: Making tab-complete.c easier to maintain

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Making tab-complete.c easier to maintain
Дата
Msg-id 20151217.150633.216859242.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Making tab-complete.c easier to maintain  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Making tab-complete.c easier to maintain  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Hello.

Ok, I withdraw the minilang solution and I'll go on Thomas's way,
which is still good to have.

At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqSggjPA8U1WV7ivW44xzboC8pci_Etmffr+ZEzxSX_ahA@mail.gmail.com>
> On Mon, Dec 14, 2015 at 8:10 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
> > I've also add (very) primitive negative pattern support and used it in
> > 5 places.  Improvement?  Examples:
> >
> >         /* ALTER TABLE xxx RENAME yyy */
> > -       else if (TailMatches5("ALTER", "TABLE", MatchAny, "RENAME", MatchAny) &&
> > -                        !TailMatches1("CONSTRAINT|TO"))
> > +       else if (TailMatches5("ALTER", "TABLE", MatchAny, "RENAME",
> > "!CONSTRAINT|TO"))
> >                 COMPLETE_WITH_CONST("TO");
> >
> >         /* If we have CLUSTER <sth>, then add "USING" */
> > -       else if (TailMatches2("CLUSTER", MatchAny) &&
> > !TailMatches1("VERBOSE|ON"))
> > +       else if (TailMatches2("CLUSTER", "!VERBOSE|ON"))
> >                 COMPLETE_WITH_CONST("USING");
> 
> +       /* Handle negated patterns. */
> +       if (*pattern == '!')
> +               return !word_matches(pattern + 1, word);
> 
> Yeah, I guess that's an improvement for those cases, and there is no
> immediate need for a per-keyword NOT operator in our cases to allow
> things of the type (foo1 OR NOT foo2). Still, in the case of this
> patch !foo1|foo2 actually means (NOT foo1 AND NOT foo2). It does not
> seem that much intuitive. Reading straight this expression it seems
> that !foo1|foo2 means actually (NOT foo1 OR foo2) because the lack of
> parenthesis. Thoughts?

I used just the same expression as Thomas in my patch since it
was enough intuitive in this context in my view. The expression
"(!FOO1)|FOO2" is a nonsence in the context of tab-completion and
won't be used in future. But it is true that "!(FOO|BAR|BAZ)" is
clearer than without the parenthesis.

We could use other characters as the operator, but it also might
make it a bit difficalt to read the meaning.

"~FOO|BAR|BAZ", "-FOO|BAR|BAZ"


"TailMatches2("CLUSTER", NEG "VERBOSE|ON")" is mere a syntax
sugar but reduces the uneasiness. But rather longer than adding
parenthesis.

As the result, I vote for "!(FOO|BAR|BAZ)", then "-FOO|BAR|BAZ"
for now.



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")

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: parallel joins, and better parallel explain
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Performance improvement for joins where outer side is unique