Re: Making tab-complete.c easier to maintain

On Wed, Dec 30, 2015 at 6:26 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Dec 30, 2015 at 3:14 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> 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:
>>>> 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.
>
> I see that you changed INSERT and DELETE (but not UPDATE) to use
> MatchesN rather than TailMatchesN. Shouldn't these stay with
> TailMatchesN for the reason Tom gave above?

Er, yeah. They had better be TailMatches, or even COPY DML stuff will be broken.
--
Michael