Re: Making tab-complete.c easier to maintain - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Making tab-complete.c easier to maintain
Date
Msg-id 20151210.173846.28949785.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Making tab-complete.c easier to maintain  (David Fetter <david@fetter.org>)
Responses Re: Making tab-complete.c easier to maintain  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Rework the way multixact truncations work
Next
From: Victor Wagner
Date:
Subject: Is postgresql on Windows compatible with flex 2.6.0?