Re: Making tab-complete.c easier to maintain

Greg Stark <stark(at)mit(dot)edu> writes:
> Fwiw I poked at the bison output to see if it would be possible to do.
> I think it's theoretically possible but a huge project and would
> create dependencies on bison internals that we would be unlikelly to
> accept.

That's the impression I got when I looked at it briefly, too. Without
some new APIs from bison it seems like it'd be way too messy/fragile.

> You would need
> a) A new protocol message to send the partial query to the server and
> get back a list of completions

As far as that goes, I'd imagined the functionality continuing to be
on the psql side. If we make it wait for a protocol upgrade, that
makes it even more improbable that it will ever happen. psql already
has its own copy of the lexer, so making it have something derived
from the grammar doesn't seem like a maintainability problem.

> b) Machinery in bison to return both all terminals that could come
> next as well as all possible terminals it could reduce to

Yeah, this is the hard part.

> d) Some way to deal with the partially parsed query to find out what
> schemas, tables, column aliases, etc should be considered for possible
> completion

I was imagining that some of that knowledge could be pushed back into the
grammar. That is, instead of just using generic nonterminals like ColId,
we'd need to have TableId, SchemaId, etc and be careful to use the
appropriate one(s) in each production of the grammar. Then, psql would
know which completion query to issue by noting which of these particular
nonterminals is a candidate for the next token right now. However, that
moves the goalposts in terms of what we'd have to be able to get back from
the alternate bison machinery.

Also, it's not just a SMOP to modify the grammar like that: it's not
at all unlikely that attempting to introduce such a finer categorization
would lead to a broken grammar, ie shift/reduce or reduce/reduce
conflicts. We couldn't be sure it would work till we've tried it.

> So I don't think it makes sense to hold up improvements today hoping
> for something like this.

Yeah, it's certainly a wishlist item rather than something that should
block shorter-term improvements.

regards, tom lane