psql & readline & win32

Magnus Hagander wrote:

Considering we have a fix, I think we need to re-enable readline on win32, and document this. However, there are a couple of things to decide on first:

1) Should it be made default? As it requires you to include this file to work, perhaps it should be set to non-default and specifically require a --with-readline? Also depends on th eanswers of a couple of questions below, I think.

Good work.

It should be the default - if we find readline we should use it. I guess
that means the installer would need to ship the readline DLL, along with
all the other third party DLLs it ships.

2) Should we ship a file of standard bindings. We're not going to get it complete, but we could get some of the most common ones in europe at least (in sweden, this would for example include "\@�${[]}~|"). Which would help people a lot.

Yes we should, at least for Windows - put it in share along with other
samples, maybe.

3) How should the inputrc file be loaded. By default, you have to type SET INPUTRC="\some\where\inputrc" before you launch psql. But we could just as easily add:
#if defined(WIN32) && defined(USE_READLINE)
rl_read_init_file(our_path_to_inputrc);
#endif
to psql, making that step a whole lot easier. Especially for people who launch psql from the startmenu, and can't specify program-specific env vars.

if user has $HOME/inputrc
load $HOME/inputrc
elsif exists $SYSTEMCONFIG/inputrc
load $SYSTEMCONFIG/inputrc
endif

Since inputrc is meant to service many applications, we shouldn't try to
bypass that.

cheers

andrew

4) Can we ship linked with readline in the installer? If not, can we ship a readline-linked binary at all, or just the source? Considering readline drags along the GPL, and not just the LGPL. (We can link either statically (default) or dynamically (separate package) to readline without problems, from what I can tell)

This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)

cheers

andrew

On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:

Magnus Hagander wrote:

4) Can we ship linked with readline in the installer? If not, can we ship
a readline-linked binary at all, or just the source? Considering readline
drags along the GPL, and not just the LGPL. (We can link either
statically (default) or dynamically (separate package) to readline
without problems, from what I can tell)

This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)

I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed. If
I were trying to use the windows installer in a commercial application, I
sure wouldn't want that liability.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat <xzilla@users.sourceforge.net> writes:

On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:

This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)

I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed.

Robert is 100% right. If the Readline people wanted non-GPL packages
linking to their code, they'd have used LGPL not GPL. We must not
ignore their clear intentions; to do so is certainly unethical and
probably illegal.

Anyone for trying to port BSD libedit to work on Windows?

(Of course, you could also treat the Windows installer as being entirely
GPL-licensed, which would effectively comply with both upstream
licenses. But I don't find that an appealing solution.)

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> wrote

Anyone for trying to port BSD libedit to work on Windows?

Maybe just let it be on Windows is acceptable. I am currently happy with my
psql without readline support on Windows, but on Unix that's hard. If
Windows users want more advanced client, there are a bunch of GUI tools.

Regards,
Qingqing

Robert Treat <xzilla@users.sourceforge.net> writes:

On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:

This has been debated ad nauseam in the past. The consensus, bar a
few people with more advanced paranoia than I suffer from,

is that we

can ;-)

I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that your

package is bsd licensed.

Robert is 100% right. If the Readline people wanted non-GPL
packages linking to their code, they'd have used LGPL not
GPL. We must not ignore their clear intentions; to do so is
certainly unethical and probably illegal.

Does it make a difference if we ship it dynamically linked against a
DLL? Because we can do that pretty easily.

Anyone for trying to port BSD libedit to work on Windows?

I googled a bit on that as well, and turns out that somebody did try it,
and it wasn't easy. And from what I can tell, not complete yet.

http://www.coldie.net/node/131

I'm sure it *can* be done, but it's probably quite a bit of work.

(Of course, you could also treat the Windows installer as
being entirely GPL-licensed, which would effectively comply
with both upstream licenses. But I don't find that an
appealing solution.)

Me either.

Though we do ship GPL stuff in it already - postgis to be specific. But
we don't link against that, we just load the module at runtime...

//Magnus

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Andrew Dunstan
Sent: Sun 1/1/2006 11:51 PM
To: Magnus Hagander
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] psql & readline & win32

4) Can we ship linked with readline in the installer?
If not, can we ship a readline-linked binary at all,
or just the source? Considering readline drags along
the GPL, and not just the LGPL. (We can link either
statically (default) or dynamically (separate package)
to readline without problems, from what I can tell)

This has been debated ad nauseam in the past. The consensus,
bar a few people with more advanced paranoia than I suffer
from, is that we can ;-)

The installer is a little different though, in that we would have to actually ship readline as part of the distro, as it's unlikely to be pre-installed on the OS. At best we would have to start shipping it's source as well, at worst it would make everything else in the package that uses it GPL as well.

IANAL of course, but my self preservation instincts tell me to err on the side of caution.

Regards, Dave

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Tom Lane
Sent: Mon 1/2/2006 3:30 AM
To: Robert Treat
Cc: pgsql-hackers@postgresql.org; Andrew Dunstan; Magnus Hagander
Subject: Re: [HACKERS] psql & readline & win32

(Of course, you could also treat the Windows installer as being entirely
GPL-licensed, which would effectively comply with both upstream
licenses. But I don't find that an appealing solution.)

Ain't gonna happen whilst pgAdmin is in there. The words 'over' and 'dead decaying corpse' spring to mind :-p

Not to mention that we can't just change the licence anyway...

/D

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org on behalf of Magnus Hagander
Sent: Mon 1/2/2006 8:08 AM
To: Tom Lane; Robert Treat
Cc: pgsql-hackers@postgresql.org; Andrew Dunstan
Subject: Re: [HACKERS] psql & readline & win32

Though we do ship GPL stuff in it already - postgis to
be specific. But we don't link against that, we just
load the module at runtime...

And of course, they *want* us to ship their code. The GNU folks most likely couldn't care less meaning they're far more likely to get annoyed if we unintentionally misinterpret the licence.

Regards, Dave

Robert Treat said:

On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:

Magnus Hagander wrote:

4) Can we ship linked with readline in the installer? If not, can we
ship
a readline-linked binary at all, or just the source? Considering
readline drags along the GPL, and not just the LGPL. (We can link
either statically (default) or dynamically (separate package) to
readline without problems, from what I can tell)

This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can
;-)

I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that your package is
bsd licensed. If I were trying to use the windows installer in a
commercial application, I sure wouldn't want that liability.

Why should we statically link it?

How well maintained is libedit? I'd feel happier about a switch if I could
find a maintained home page for it.

cheers

andrew

I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that

your package

is bsd licensed. If I were trying to use the windows

installer in a

commercial application, I sure wouldn't want that liability.

Why should we statically link it?

How well maintained is libedit? I'd feel happier about a
switch if I could find a maintained home page for it.

There appears to be more than one (!)

There's one on http://sourceforge.net/projects/libedit/, and one on
http://www.thrysoee.dk/editline/ at least. And
http://www.s11n.net/editline/. And
http://packages.qa.debian.org/e/editline.html.

The second one supports cygwin, but not mingw. The first one I have no
idea, but it has made no release since 2001 so it doesn't seem very
active, whereas the second one made a release in oct 2005. I think the
second one is the one the guy in the blog post I sent before was
referring to, but I'm not sure.

//Magnus

Anyone for trying to port BSD libedit to work on Windows?

Maybe just let it be on Windows is acceptable. I am currently
happy with my psql without readline support on Windows, but
on Unix that's hard. If Windows users want more advanced
client, there are a bunch of GUI tools.

Well, we should *at least* provide it from the source build. Since it
does work (with a small kludge, but it does work).
Me, I'm not fully happy with psql on win32. I want my tab completion!
(which the gui tools don't do either, from what I can tell. At least
pgadmin doesn't. Yet.)

If we only allow it from build-from-source, it's no different from any
other platform, license-wise.

//Magnus

2) Should we ship a file of standard bindings. We're not

going to get it complete, but we could get some of the most
common ones in europe at least (in sweden, this would for
example include "\@£${[]}~|"). Which would help people a lot.

Yes we should, at least for Windows - put it in share along
with other samples, maybe.

That was my second question on that - where to put it, and how to find it.

3) How should the inputrc file be loaded. By default, you

have to type SET INPUTRC="\some\where\inputrc" before you
launch psql. But we could just as easily add:

#if defined(WIN32) && defined(USE_READLINE)
rl_read_init_file(our_path_to_inputrc);
#endif
to psql, making that step a whole lot easier. Especially for

people who launch psql from the startmenu, and can't specify
program-specific env vars.

if user has $HOME/inputrc
load $HOME/inputrc
elsif exists $SYSTEMCONFIG/inputrc
load $SYSTEMCONFIG/inputrc
endif

Since inputrc is meant to service many applications, we
shouldn't try to bypass that.

Actually, I think readline handles that and we can't turn it off. Though I think I need to set INPUTRC=<something> to make it work on win32, it doesn't know abuot the All Users profile for example.

I was thinking of a completement to the inputrc. Which would be somethign like:
if exists $SYSTEMCONFIG/psql.inputrc
load $SYSTEMCONFIG/psql.inputrc
endif
if exists $HOME/inputrc <-- this part handled by readline, not us
laod $HOME/inputrc <-- this part handled by readline, not us
endif

//Magnus

Magnus Hagander writes:

2) Should we ship a file of standard bindings. We're not

going to get it complete, but we could get some of the most
common ones in europe at least (in sweden, this would for
example include "\@�${[]}~|"). Which would help people a lot.

Yes we should, at least for Windows - put it in share along
with other samples, maybe.

That was my second question on that - where to put it, and how to find it.

IMHO an elegant solution would be to expose readline's macro/bind
mechanism with a psql command, e.g. like bash's "bind" does. This way
one could put the macros into the system-wide psqlrc.

regards,
Andreas

Tom Lane <tgl@sss.pgh.pa.us> writes:

Robert Treat <xzilla@users.sourceforge.net> writes:

On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:

This has been debated ad nauseam in the past. The consensus, bar a few
people with more advanced paranoia than I suffer from, is that we can ;-)

I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed.

Robert is 100% right.

I suspect Andrew was mixing up two different aspects of this.

There isn't much dispute that shipping a binary linked (statically or
dynamically) with a library depends on your license to distribute derivative
works of that library. Ie, that Andrew's wrong and shipping a binary linked
with a GPL'd library is only legal if you follow the terms of the GPL.

There is controversy over whether the software that requires that library
becomes a derivative work itself. For example whether a Gimp plugin that is
useless without the Gimp would be a derivative work of the Gimp itself and be
undistributable unless you followed the Gimp license terms.

Most people do agree when the question is put for something like Gimp plugins
but seem to draw a distinction between that and things like Postgres that
happen to depend on linking with libreadline where libreadline is a rather
incidental part of the whole system.

In RMS's view (and the view of the actual practicing lawyers who have examined
this question when real money was on the line, but then I guess lawyers are
paid well to have more advanced cases of paranoia than Andrew) is that there's
no such distinction in law and having software that depends on libreadline is
just as much bound by the GPL as a Gimp plugin.

But that said, in the case of a binary there's really no controversy. A binary
that's linked against libreadline clearly can't be legally distributed without
following the terms of the GPL.

--
greg

On Mon, 2 Jan 2006 16:27:48 -0600 (CST)
"Andrew Dunstan" <andrew@dunslane.net> wrote:

Our BSD license is recognised as a GPL-compatible license.

Recognized by who? The only two entities that I can think of that
matter would be GNU itself or the courts.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

"Andrew Dunstan" <andrew@dunslane.net> writes:

The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
Readline is free software, distributed under the terms of the GNU General
Public License, version 2. This means that if you want to use Readline in a
program that you release or distribute to anyone, the program must be free
software and have a GPL-compatible license.

Our BSD license is recognised as a GPL-compatible license.

Whoever wrote that doesn't seem to have bothered to read the GPL. The
language of the GPL is exceedingly clear and specific:

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

It says THIS LICENSE. There is nothing at all about "compatible
licenses" anywhere in the document. (Quote taken directly from the copy
of the GPL in readline-4.2a.tar.gz.)

I really don't see that the Windows binary installer is any different from
the binary installers that most Linux distros have, and they are all linked
with readline.

... and they are all GPL-licensed.

The fundamental problem here is that we don't want the Windows
distribution of PG to become effectively GPL-licensed. There's no
issue if someone builds their own copy and doesn't redistribute it,
but there is a big issue if we are distributing a heavily used port
in a way that violates someone else's license.

regards, tom lane

Greg Stark said:

Tom Lane <tgl@sss.pgh.pa.us> writes:

Robert Treat <xzilla@users.sourceforge.net> writes:

On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:

This has been debated ad nauseam in the past. The consensus, bar a
few people with more advanced paranoia than I suffer from, is that
we can ;-)

I don't think it is good practice to ship packaged software that is
statically linked to a gpl library and then claim that your package
is bsd licensed.

Robert is 100% right.

I suspect Andrew was mixing up two different aspects of this.

There isn't much dispute that shipping a binary linked (statically or
dynamically) with a library depends on your license to distribute
derivative works of that library. Ie, that Andrew's wrong and shipping
a binary linked with a GPL'd library is only legal if you follow the
terms of the GPL.

There is controversy over whether the software that requires that
library becomes a derivative work itself. For example whether a Gimp
plugin that is useless without the Gimp would be a derivative work of
the Gimp itself and be undistributable unless you followed the Gimp
license terms.

Most people do agree when the question is put for something like Gimp
plugins but seem to draw a distinction between that and things like
Postgres that happen to depend on linking with libreadline where
libreadline is a rather incidental part of the whole system.

In RMS's view (and the view of the actual practicing lawyers who have
examined this question when real money was on the line, but then I
guess lawyers are paid well to have more advanced cases of paranoia
than Andrew) is that there's no such distinction in law and having
software that depends on libreadline is just as much bound by the GPL
as a Gimp plugin.

But that said, in the case of a binary there's really no controversy. A
binary that's linked against libreadline clearly can't be legally
distributed without following the terms of the GPL.

First, note that readline is ONLY used in psql. So there is no question of
GPL for most of our code.

In any case, you don't have to GPL the code, as I understand it.

The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:

Readline is free software, distributed under the terms of the GNU General
Public License, version 2. This means that if you want to use Readline in a
program that you release or distribute to anyone, the program must be free
software and have a GPL-compatible license.

Our BSD license is recognised as a GPL-compatible license.

OTOH, if I were a company distributing a closed source postgres
distribution, I would probably not link my psql with readline.

Interestingly, some Gnu software (e.g. bc) has the option of linking with
readline or libedit. It's really a pity that libedit doesn't seem to be as
well maintained.

I really don't see that the Windows binary installer is any different from
the binary installers that most Linux distros have, and they are all linked
with readline.

cheers

andrew

""Magnus Hagander"" <mha@sollentuna.net> wrote

Well, we should *at least* provide it from the source build. Since it
does work (with a small kludge, but it does work).
Me, I'm not fully happy with psql on win32. I want my tab completion!
(which the gui tools don't do either, from what I can tell. At least
pgadmin doesn't. Yet.)

Yeah, I am not against doing so and having more features is always cool! But
I just suspect if we can afford the cost. Actually I tried a little bit on
the "thrysoee" version you mentioned:

$ ./config.guess
i686-pc-mingw32
$./configure
...
configure: error: libtermcap, libcurses or libncurses are required!

This may give us a hint that port is not very easy though.

Regards,
Qingqing

Tom Lane said:

"Andrew Dunstan" <andrew@dunslane.net> writes:

The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
Readline is free software, distributed under the terms of the GNU
General Public License, version 2. This means that if you want to use
Readline in a program that you release or distribute to anyone, the
program must be free software and have a GPL-compatible license.

Our BSD license is recognised as a GPL-compatible license.

Whoever wrote that doesn't seem to have bothered to read the GPL. The
language of the GPL is exceedingly clear and specific:

The page links to this: http://www.gnu.org/licenses/license-list.html which
lists the BSD licence without the advertising clause as a GPL-compatible
free software license, of which it says: "This means you can combine a
module which was released under that license with a GPL-covered module to
make one larger program."

So in the highly unlikely event that we were challenged by the FSF we could
point to that and say "we just did what your web site told us we could do."

cheers

andrew

On Monday 02 January 2006 18:21, Andrew Dunstan wrote:

Tom Lane said:

"Andrew Dunstan" <andrew@dunslane.net> writes:

The readline home page at
http://cnswww.cns.cwru.edu/~chet/readline/rltop.html says:
Readline is free software, distributed under the terms of the GNU
General Public License, version 2. This means that if you want to use
Readline in a program that you release or distribute to anyone, the
program must be free software and have a GPL-compatible license.

Our BSD license is recognised as a GPL-compatible license.

Whoever wrote that doesn't seem to have bothered to read the GPL. The
language of the GPL is exceedingly clear and specific:

The page links to this: http://www.gnu.org/licenses/license-list.html which
lists the BSD licence without the advertising clause as a GPL-compatible
free software license, of which it says: "This means you can combine a
module which was released under that license with a GPL-covered module to
make one larger program."

yowza! Andrew you are reading that backwards. Those aren't licenses you can
combine gpl code with and be ok, those are licenses you can combine with gpl
code and release gpl products! Non-compatible free software licenses means
the free software license contains additional restrictions that make it
unacceptable to include in gpl code!! Oy vey!!!

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

"Andrew Dunstan" <andrew@dunslane.net> writes:

The page links to this: http://www.gnu.org/licenses/license-list.html which
lists the BSD licence without the advertising clause as a GPL-compatible
free software license, of which it says: "This means you can combine a
module which was released under that license with a GPL-covered module to
make one larger program."

You are misinterpreting the intent of that page completely.

What the GNU people mean by "GPL compatible" is that you can combine
GPL code with code licensed with a compatible license, and then
redistribute the result UNDER THE GPL. (There are many licenses for
which this is not so, and you basically couldn't redistribute such a
combined work at all.) There is no situation in which they intend to
let you redistribute combined works under the other license.

regards, tom lane

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

The page links to this: http://www.gnu.org/licenses/license-list.html which
lists the BSD licence without the advertising clause as a GPL-compatible
free software license, of which it says: "This means you can combine a
module which was released under that license with a GPL-covered module to
make one larger program."

You are misinterpreting the intent of that page completely.

What the GNU people mean by "GPL compatible" is that you can combine
GPL code with code licensed with a compatible license, and then
redistribute the result UNDER THE GPL. (There are many licenses for
which this is not so, and you basically couldn't redistribute such a
combined work at all.) There is no situation in which they intend to
let you redistribute combined works under the other license.

Ok, I accept this. Their wording is certainly unfortunate, especuially
when you combine it with what is said obn the redline home page.

Incidentally, there is a place that libedit is being maintained,
apparently: http://www.thrysoee.dk/editline/

Unfortunately, it doesn't seem to build on mingw :-(

cheers

andrew

Well, we should *at least* provide it from the source

build. Since it

does work (with a small kludge, but it does work).
Me, I'm not fully happy with psql on win32. I want my tab

completion!

(which the gui tools don't do either, from what I can tell.

At least

pgadmin doesn't. Yet.)

Yeah, I am not against doing so and having more features is
always cool! But I just suspect if we can afford the cost.
Actually I tried a little bit on the "thrysoee" version you mentioned:

$ ./config.guess
i686-pc-mingw32
$./configure
...
configure: error: libtermcap, libcurses or libncurses are required!

This may give us a hint that port is not very easy though.

You can get pdcurses to get past that step. But it's still not easy. See
for example http://www.coldie.net/node/131.

//Magnus

On Jan 2, 2006, at 4:00 AM, Magnus Hagander wrote:

Me, I'm not fully happy with psql on win32. I want my tab completion!
(which the gui tools don't do either, from what I can tell. At least
pgadmin doesn't. Yet.)

Mine has tab completion adapted from psql :). There are also commands
for specific completion types, e.g. complete table, complete
function, etc.

I hope to have a beta out soon with 8.1 psql and updated tab
completion for the new commands (roles, etc).

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

John DeSoi schrieb:

On Jan 2, 2006, at 4:00 AM, Magnus Hagander wrote:

Me, I'm not fully happy with psql on win32. I want my tab completion!
(which the gui tools don't do either, from what I can tell. At least
pgadmin doesn't. Yet.)

Mine has tab completion adapted from psql :). There are also commands
for specific completion types, e.g. complete table, complete function,
etc.

I hope to have a beta out soon with 8.1 psql and updated tab completion
for the new commands (roles, etc).

Great! I once experimented with dropdowns in textarea too but lost
grip a bit.

Me, I'm not fully happy with psql on win32. I want my tab

completion!

(which the gui tools don't do either, from what I can tell.

At least

pgadmin doesn't. Yet.)

Mine has tab completion adapted from psql :). There are also
commands for specific completion types, e.g. complete table,
complete function, etc.

Well, yours ain't free, so it doesn't really help me in this case ;-)
And doesn't run on Linux, IIRC. Might help me in other cases, though,
I'll keep it in mind for that.

I hope to have a beta out soon with 8.1 psql and updated tab
completion for the new commands (roles, etc).

Sounds nice.

//Magnus

Magnus Hagander said:

Me, I'm not fully happy with psql on win32. I want my tab

completion!

(which the gui tools don't do either, from what I can tell.

At least

pgadmin doesn't. Yet.)

Mine has tab completion adapted from psql :). There are also
commands for specific completion types, e.g. complete table,
complete function, etc.

Well, yours ain't free, so it doesn't really help me in this case ;-)
And doesn't run on Linux, IIRC. Might help me in other cases, though,
I'll keep it in mind for that.

We really need psql working properly, regardless of other clients, if
possible.
cheers

andrew

Would the easiest solution be to make a patch to readline for Win32, and
only allow Win32 to link to readline if that patch is in readline, and
spit out a compile error if readline doesn't have that patch.

As far as the license, psql spits out a copyright notice as it starts.
It would be a shame to have to mention GPL in there.

Can we get any companies to fund a port of libedit to Win32? What does
readline have that Win32 native editing does not?

---------------------------------------------------------------------------

Magnus Hagander wrote:

Getting started early this year, I've finally found a way around the
issues with readline on win32. And it just took a little bit of google
research and some testing.

Recap of the problem: When running psql in a readline enabled mode on
win32, any character requiring the AltGr key to generate will not work.
In a lot of non-US locales, this includes the backslash key, which
makes psql pretty darn unusable. The "fix" for this that went into 8.0
is to disable readline on win32 pending a fix.

Now, this can be fixed. And it's as simple as specifying an inputrc
file. For backslash, this file needs to contain: "\M-\\": "\\"

And then similarly for every other character requiring AltGr.

Considering we have a fix, I think we need to re-enable readline on
win32, and document this. However, there are a couple of things to
decide on first:

1) Should it be made default? As it requires you to include this file
to work, perhaps it should be set to non-default and specifically
require a --with-readline? Also depends on th eanswers of a couple of
questions below, I think.

2) Should we ship a file of standard bindings. We're not going to get
it complete, but we could get some of the most common ones in europe
at least (in sweden, this would for example include "\@?${[]}~|").
Which would help people a lot.

3) How should the inputrc file be loaded. By default, you have to type
SET INPUTRC="\some\where\inputrc" before you launch psql. But we could
just as easily add: #if defined(WIN32) && defined(USE_READLINE)
rl_read_init_file(our_path_to_inputrc); #endif to psql, making that
step a whole lot easier. Especially for people who launch psql from
the startmenu, and can't specify program-specific env vars.

If we wanted to, we could even bind the keys using rl_parse_and_bind()
or similar, but keeping it in a separate file makes it possible to edit
it without recompiling, which is a definite plus.

4) Can we ship linked with readline in the installer? If not, can we
ship a readline-linked binary at all, or just the source? Considering
readline drags along the GPL, and not just the LGPL. (We can link either
statically (default) or dynamically (separate package) to readline
without problems, from what I can tell)

I think we ship readline-linked RPMs, but I'm not sure about that?

Now even if we can't ship readline linked binaries in the installer,
it's still a good thing to provide the ability to build them, of course
:-)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Would the easiest solution be to make a patch to readline for
Win32, and only allow Win32 to link to readline if that patch
is in readline, and spit out a compile error if readline
doesn't have that patch.

What would we patch it with? I don't think anybody has found a problem
there, this is a separate file that you ship along with it.

As far as the license, psql spits out a copyright notice as
it starts.
It would be a shame to have to mention GPL in there.

Even that may not be enough. This is the GPL we're talking about.

Can we get any companies to fund a port of libedit to Win32?

That would be nice. Takers?

What does readline have that Win32 native editing does not?

tab completion, for one. Some editing keys, IIRC. I thought history, but
it does seem we have history workign on native :)

//Magnus

Magnus Hagander wrote:

Would the easiest solution be to make a patch to readline for
Win32, and only allow Win32 to link to readline if that patch
is in readline, and spit out a compile error if readline
doesn't have that patch.

What would we patch it with? I don't think anybody has found a problem
there, this is a separate file that you ship along with it.

Well, the problem is that it handles backslash incorrectly. We could
patch that in the readline source rather than playing with a
configuaration file.

As far as the license, psql spits out a copyright notice as
it starts.
It would be a shame to have to mention GPL in there.

Even that may not be enough. This is the GPL we're talking about.

At that point, psql becomes GPL, no question.

Can we get any companies to fund a port of libedit to Win32?

That would be nice. Takers?

What does readline have that Win32 native editing does not?

tab completion, for one. Some editing keys, IIRC. I thought history, but
it does seem we have history workign on native :)

I think what we don't have is saving history between psql uses.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Magnus Hagander wrote:

What would we patch it with? I don't think anybody has found a problem
there, this is a separate file that you ship along with it.

Well, the problem is that it handles backslash incorrectly. We could
patch that in the readline source rather than playing with a
configuaration file.

Do the readline developers agree that it's "incorrect"? I could see
shipping a patch as a short-term band-aid, but not if the patch isn't
going to be accepted upstream.

Even that may not be enough. This is the GPL we're talking about.

At that point, psql becomes GPL, no question.

Which means it's not happening, no?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Magnus Hagander wrote:

What would we patch it with? I don't think anybody has found a problem
there, this is a separate file that you ship along with it.

Well, the problem is that it handles backslash incorrectly. We could
patch that in the readline source rather than playing with a
configuaration file.

Do the readline developers agree that it's "incorrect"? I could see
shipping a patch as a short-term band-aid, but not if the patch isn't
going to be accepted upstream.

No idea. We need to develop the patch and submit it.

Even that may not be enough. This is the GPL we're talking about.

At that point, psql becomes GPL, no question.

Which means it's not happening, no?

To clearify, I meant the psql binary becomes GPL.

When we build psql with readline, which is our default on many
platforms, we are already be GPL'ing psql, at least according to the
copyright holders, FSF. We are dynamic linking on many platforms, but
according to the FSF, it makes it GPL.

I do think that adding readline features to the Win32 psql doesn't
warrant the license change for the psql binary.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

What would we patch it with? I don't think anybody has found a
problem there, this is a separate file that you ship along with it.

Well, the problem is that it handles backslash incorrectly.

We could

patch that in the readline source rather than playing with a
configuaration file.

Do the readline developers agree that it's "incorrect"? I
could see shipping a patch as a short-term band-aid, but not
if the patch isn't going to be accepted upstream.

I have seen no such agreement. The ability to reconfigure the keys is
definitly a feature, so it could perhaps be argued to be that. In
general, I don't think they care too much about win32 :-( Which is
another thing that makes libedit a lot more encouraging - if it could be
made working.

Bruce wrote:

I think what we don't have is saving history between psql uses.

We do keep history if the new psql is startede in the same
commandprompt. If you start a new cmd, history gets reset. (Which is
what happens if you start it from the start menu)

//Magnus

//Magnus

Magnus Hagander wrote:

What would we patch it with? I don't think anybody has found a
problem there, this is a separate file that you ship along with it.

Well, the problem is that it handles backslash incorrectly.

We could

patch that in the readline source rather than playing with a
configuaration file.

Do the readline developers agree that it's "incorrect"? I
could see shipping a patch as a short-term band-aid, but not
if the patch isn't going to be accepted upstream.

I have seen no such agreement. The ability to reconfigure the keys is
definitly a feature, so it could perhaps be argued to be that. In
general, I don't think they care too much about win32 :-( Which is
another thing that makes libedit a lot more encouraging - if it could be
made working.

I would love us to use libedit more, and our configure flags for libedit
are improved in 8.2.

I think what we don't have is saving history between psql uses.

We do keep history if the new psql is startede in the same
commandprompt. If you start a new cmd, history gets reset. (Which is
what happens if you start it from the start menu)

Ah, OK, I was testing from the start menu.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

At that point, psql becomes GPL, no question.

Which means it's not happening, no?

To clearify, I meant the psql binary becomes GPL.

There is no such thing as "the binary becomes GPL". GPL applies to
the source code.

When we build psql with readline, which is our default on many
platforms, we are already be GPL'ing psql, at least according to the
copyright holders, FSF.

No, we are NOT doing that, not even according to FSF. Our usage of
a pre-installed readline library falls under this exception in the
standard GPL terms:

However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

When we link to a readline library that is normally present on the
target system, we do not become covered by the GPL, because of this
exception. But shipping readline in our package would be a flat
violation of the GPL unless we are willing to relicense.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

At that point, psql becomes GPL, no question.

Which means it's not happening, no?

To clearify, I meant the psql binary becomes GPL.

There is no such thing as "the binary becomes GPL". GPL applies to
the source code.

OK.

When we build psql with readline, which is our default on many
platforms, we are already be GPL'ing psql, at least according to the
copyright holders, FSF.

No, we are NOT doing that, not even according to FSF. Our usage of
a pre-installed readline library falls under this exception in the
standard GPL terms:

However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

When we link to a readline library that is normally present on the
target system, we do not become covered by the GPL, because of this
exception. But shipping readline in our package would be a flat
violation of the GPL unless we are willing to relicense.

Interesting, but that phrase is for what you need to distribute for an
already-GPL source code. See the "GPL-related disputes" section:

http://en.wikipedia.org/wiki/Gpl

and an old email from me on the topic:

http://archives.postgresql.org/pgsql-general/2003-08/msg01811.php

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

When we build psql with readline, which is our default on many
platforms, we are already be GPL'ing psql, at least according to the
copyright holders, FSF.

No, we are NOT doing that, not even according to FSF. Our usage of
a pre-installed readline library falls under this exception in the
standard GPL terms:

However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

When we link to a readline library that is normally present on the
target system, we do not become covered by the GPL, because of this
exception. But shipping readline in our package would be a flat
violation of the GPL unless we are willing to relicense.

Interesting, but that phrase is for what you need to distribute for an
already-GPL source code. See the "GPL-related disputes" section:

http://en.wikipedia.org/wiki/Gpl

and an old email from me on the topic:

http://archives.postgresql.org/pgsql-general/2003-08/msg01811.php

Let's just get off this track. We can easily tie ourselves up in knots
over it. Moving to libedit everywhere would be a good way to go if it's
achievable.

Incidentally, the exception quoted probably doesn't apply to any closed
source Unix any more than it does to Windows - last I looked none of
them normally ship libreadline. So presumably it's desirable to make
sure libedit works at least on those platforms.

So what's needed to bring libedit up to scratch? Are there any platforms
where it works as well as libreadline? On which platforms does it have
reduced or no functionality?

cheers

andrew

Tom Lane <tgl@sss.pgh.pa.us> writes:

To clearify, I meant the psql binary becomes GPL.

There is no such thing as "the binary becomes GPL". GPL applies to
the source code.

That's an odd thing to say. The binary is as much covered by copyright as the
source and can't be distributed without satisfying the requirements of the
license that covers it. The GPL requirements mean you can't distribute a
binary that depends on readline without including the corresponding source
code.

I'm not sure that's really an onerous requirement. It just means if you're a
commercial vendor selling a binary-only version of Postgres you can't link
your binary-only version against readline and then distribute it. Which should
be pretty obvious anyways.

(The exception Tom points out might even make it legal to distribute a Linux
compile of Postgres linked against readline since most Linux distributions
include readline. That wasn't true when that exception was written though so
you may want to check with your lawyer about that.)

I think people are mixing this stuff up with the less obvious claim about
programs like postgres being deemed "derivative works" of libraries like
readline because they "depend" on them. Postgres doesn't really depend in any
real sense on readline so I can't see that argument working in this case
anyways. If there was some GPLed library that Postgres couldn't work usefully
without then there might be a real need for a non-GPL'd version of that
library.

--
greg

On Mon, Feb 13, 2006 at 01:19:46PM -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

When we build psql with readline, which is our default on many
platforms, we are already be GPL'ing psql, at least according to the
copyright holders, FSF.

When we link to a readline library that is normally present on the
target system, we do not become covered by the GPL, because of this
exception. But shipping readline in our package would be a flat
violation of the GPL unless we are willing to relicense.

Umm, whatever happens, the licence on psql doesn't change. If we link
compile and link psql with readline and distribute the result, all that
means is that the combined work must be distributed under terms
compliant with the GPL (eg source availability, etc). The code doesn't
"become" GPL'd.

The licence on psql remains unchanged and if someone took the result
and deleted all the GPL stuff, the result would still be licenced as
BSD.

Only the copyright holder can change the licence of code. All the GPL
does in a combined work is require that any parts have the at least the
same freedoms as required by the GPL. Since BSD is compatable with (ie
more free than) the GPL, it's all ok, but at no point is any licence
changed.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/