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

On Thu, Oct 22, 2015 at 04:05:06PM -0700, Tom Lane wrote:
> David Fetter <david@fetter.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.

I should have made this more clear.  I am not an IP attorney and don't
play one on TV, but this is what I've gotten out of conversations with
IP attorneys on this subject:

- If we allow people to disable readline at compile time, the software is not GPL even if only libreadline would add
thecommand line editing capability.
 

- When people do compile with libreadline, the only software affected by libreadine's license is the binary to which it
islinked, namely the psql client. 
 
To be affective negatively by libreadline's viral license, an entity
would need to fork the psql client in proprietary ways that they did
not wish not to make available to end users, at the same time linking
in libreadline.

Maybe I'm missing something big, but I really don't see people out
there shipping a libreadline-enabled psql client, details of whose
source they'd want to keep a deep, dark secret.

If this gets to matter, we can probably get /pro bono/ work from IP
attorneys specializing in just this kind of thing.

> 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.

Great!

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate