Re: Making tab-complete.c easier to maintain

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Making tab-complete.c easier to maintain
Date: 2015-12-19 23:36:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> 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 poked into this and found that it's really not hard, if you don't mind
still another global variable associated with tab-completion. See
attached patch.

The main objection to this change might be speed, but I experimented with
the longest query in information_schema.sql (CREATE VIEW usage_privileges,
162 lines) and found that pressing tab at the end of that seemed to take
well under a millisecond on my workstation. So I think it's probably
insignificant, especially compared to any of the code paths that send a
query to the server for tab completion.

regards, tom lane

Attachment Content-Type Size
multiline-tab-completion.patch text/x-diff 15.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2015-12-20 01:21:14 Re: An unlikely() experiment
Previous Message Peter Geoghegan 2015-12-19 23:28:58 Re: Refactoring speculative insertion with unique indexes a little