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.paqu...@gmail.com>
wrote in <cab7npqsggjpa8u1wv7ivw44xzboc8pci_etmffr+zezxsx_...@mail.gmail.com>
> On Mon, Dec 14, 2015 at 8:10 AM, Thomas Munro
> <thomas.mu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
