Обсуждение: psql & readline & win32
Getting started early this year, I've finally found a way around the issues with readline on win32. And it just took a
littlebit 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
generatewill 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
coupleof 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
andspecifically 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
commonones 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
launchpsql. 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
specifyprogram-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
makesit 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
buildthem, of course :-)
//Magnus
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
coupleof 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
andspecifically 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
commonones 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
launchpsql. 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
specifyprogram-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
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
-----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'sunlikely to be pre-installed on the OS. At best we would have to start shipping it's source as well, at worst it wouldmake 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 likelyto get annoyed if we unintentionally misinterpret the licence. Regards, Dave
> > 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
makeit 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
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
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 theProgram 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
""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,
Pennsylvania19073
> 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, Pennsylvania19073
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, Pennsylvania19073
> >> 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, Pennsylvania19073
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 aspecial exception, the source code distributed need not includeanything that is normally distributed (in
eithersource or binaryform) with the major components (compiler, kernel, and so on) of theoperating system on which the
executableruns, unless that componentitself 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, Pennsylvania19073
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/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.