Re: Making tab-complete.c easier to maintain

David Fetter <david(at)fetter(dot)org> writes:
> On Thu, Oct 22, 2015 at 02:36:53PM -0700, Tom Lane wrote:
>> I have no very good idea how to do that, though. Bison does have a
>> notion of which symbols are possible as the next symbol at any given
>> parse point, but it doesn't really make that accessible. There's a lack
>> of cooperation on the readline side too: we'd need to be able to see the
>> whole query buffer not just the current line.

> This may be on point:

> http://stackoverflow.com/questions/161495/is-there-a-nice-way-of-handling-multi-line-input-with-gnu-readline

> I suspect we might have to stop pretending to support alternatives to
> libreadline if we went that direction, not that that would necessarily
> be a bad idea.

Given the license issues around GNU readline, requiring it seems like
probably a non-starter.

It strikes me though that maybe we don't need readline's cooperation.
I think it's already true that the previous lines of the query buffer
are stashed somewhere that psql knows about, so in principle we could
sew them together with the current line. That might be a project worth
tackling on its own, since we could make the existing code smarter about
multiline queries, whether or not we ever get to a grammar-based solution.

regards, tom lane