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

From Greg Stark
Subject Re: Making tab-complete.c easier to maintain
Date
Msg-id CAM-w4HOEKuW-dbv8UUhVgpaEK6ZNUWT6631BsZX6Hh22aZxouQ@mail.gmail.com
Whole thread Raw
In response to Re: Making tab-complete.c easier to maintain  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 22, 2015 at 10:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What I would like is to find a way to auto-generate basically this entire
> file from gram.y.  That would imply going over to something at least
> somewhat parser-based, instead of the current way that is more or less
> totally ad-hoc.  That would be a very good thing though, because the
> current way gives wrong answers not-infrequently, even discounting cases
> that it's simply not been taught about.

I always assumed the reason we didn't use the bison grammar table to
generate completions was because the grammar is way too general and
there would be way too many spurious completions that in practice
nobody would ever be interested in. I assumed it was an intentional
choice that it was more helpful to complete things we know people
usually want rather than every theoretically possible next token.

If that's not true then maybe I'll poke at this sometime. But I agree
with the other part of this thread that that would be totally
experimental and even if we had a working patch it would be a long
time before the user experience was up to the same level as the
current behaviour. I suspect it would involve sending the partial
query to the server for parsing and asking for feedback on completions
using the grammar parser table and the search_path object resolution
rules in effect.


-- 
greg



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Making tab-complete.c easier to maintain
Next
From: Korry Douglas
Date:
Subject: Re: Patch (2): Implement failover on libpq connect level.