Re: Making tab-complete.c easier to maintain

On Sun, Dec 20, 2015 at 8:08 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Sun, Dec 20, 2015 at 6:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 1. I think it would be a good idea to convert the matching rules for
>> backslash commands too. To do that, we'd need to provide a case-sensitive
>> equivalent to word_match and the matching macros. I think we'd also have
>> to extend word_match to allow a trailing wildcard character, maybe "*".

I am not really sure I follow much the use of the wildcard, do you
mean to be able to work with the [S] extensions of the backslash
commands which are not completed now? I am attaching a patch that adds
support for a case-sensitive comparison facility without this wildcard
system, simplifying the backslash commands.

>> 2. I believe that a very large fraction of the TailMatches() rules really
>> ought to be Matches(), ie, they should not consider matches that don't
>> start at the start of the line. And there's another bunch that could
>> be Matches() if the author hadn't been unaccountably lazy about checking
>> all words of the expected command. If we converted as much as we could
>> that way, it would make psql_completion faster because many inapplicable
>> rules could be discarded after a single integer comparison on
>> previous_words_count, and it would greatly reduce the risk of inapplicable
>> matches. We can't do that for rules meant to apply to DML statements,
>> since they can be buried in WITH, EXPLAIN, etc ... but an awful lot of
>> the DDL rules could be changed.

Yep, clearly. We may gain a bit of performance by matching directly
with an equal number of words using Matches instead of a lower bound
with TailMatches. I have looked at this thing and hacked a patch as
attached.

>> 3. The HeadMatches macros are pretty iffy because they can only look back
>> nine words. I'm tempted to redesign get_previous_words so it just
>> tokenizes the whole line rather than having an arbitrary limitation.
>> (For that matter, it's long overdue for it to be able to deal with
>> multiline input...)
>>
>> I might go look at #3, but I can't currently summon the energy to tackle
>> #1 or #2 --- any volunteers?

#3 has been already done in the mean time...

> I could have a look at both of them and submit patch for next CF, both
> things do not seem that much complicated.

Those things are as well added to the next CF.
--
Michael