On Thu, Dec 10, 2015 at 5:38 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> I'm unhappy with context matching using previous_words in two
> points. Current code needs human-readable comments describing
> almost all matchings. It is hard to maintain and some of them
> actually are wrong. The hardness is largely alleviated by
> Thomas's approach exept for complex ones. Another is that
> previous_words method is not-enough adaptable for optional words
> in syntax. For example, CREATE INDEX has a complex syntax and
> current rather complex code does not cover it fully (or enough).
Yep.
> On the other hand, regexp is quite heavy-weight. Current code
> does one completion in 1 milliseconds but regexps simplly
> replaced with current matching code takes nearly 100ms on my
> environment. But appropriate refactoring reduces it to under 10
> ms.
That's quite a difference in performance. A good responsiveness is
always nice for such things to make the user confortable.
> If we need more powerful completion (which means it covers more
> wide area of syntax including more optional words), Thomas's
> approach would face difficulties of another level of
> complexity. I'd like to overcome it.
That's a valid concern for sure because the patch of Thomas is not
much smart in emulating negative checks, still the main idea to not
rely anymore on some checks based on pg_strcmp or similar but have
something that is list-based, with a primitive sub-language in it is
very appealing.
As a next step, more committer and hacker input (people who have
worked on tab completion of psql) would be a nice next step. IMO, as
someone who has hacked tab-complete.c a couple of times I think that
Thomas' patch has merit, now it would make backpatch harder. Also, if
we prioritize a dynamically generated tab completion using gram.y, so
be it and let's reject both patches then...
--
Michael