Re: Making tab-complete.c easier to maintain

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

At Wed, 9 Dec 2015 10:31:06 -0800, David Fetter <david@fetter.org> wrote in <20151209183106.GC10778@fetter.org>
> On Wed, Dec 09, 2015 at 03:49:20PM +0000, Greg Stark wrote:
> > On Wed, Dec 9, 2015 at 2:27 PM, David Fetter <david@fetter.org> wrote:
> > > Agreed that the "whole new language" aspect seems like way too big a
> > > hammer, given what it actually does.
> > 
> > Which would be easier to update when things change?
> 
> This question seems closer to being on point with the patch sets
> proposed here.

I agree to some extent.

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

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.

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.

> > Which would be possible to automatically generate from gram.y?
> 
> This seems like it goes to a wholesale context-aware reworking of tab
> completion rather than the myopic ("What has happened within the past N
> tokens?", for slowly increasing N) versions of tab completions in both
> the current code and in the two proposals here.
> 
> A context-aware tab completion wouldn't care how many columns you were
> into a target list, or a FROM list, or whatever, as it would complete
> based on the (possibly nested) context ("in a target list", e.g.)
> rather than on inferences made from some slightly variable number of
> previous tokens.

It's unknown to me how much the full-context-aware completion
makes me happy. But it would be another high-wall to overcome..

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Rework the way multixact truncations work
Следующее
От: Victor Wagner
Дата:
Сообщение: Is postgresql on Windows compatible with flex 2.6.0?