Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm, this is not what we agreed.
Are
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
Humm,
I am not going to be spending my time on it and I doubt anyone else will.
Really, I thought there were a number of people who liked it. New text
is:
o Add \# to list and execute command history
Are you sure you want it removed?
Well let me put it this way. I think my idea
Joshua D. Drake wrote:
I am not going to be spending my time on it and I doubt anyone else will.
Really, I thought there were a number of people who liked it. New text
is:
o Add \# to list and execute command history
Are you sure you want it removed?
Well let me
Added to TODO:
o Add \# to list command history like \s, but with line numbers
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php
---
Joshua D. Drake wrote:
Hello,
O.k. this is my
Joshua D. Drake wrote:
On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Richard Troy [EMAIL PROTECTED] writes:
... it occurs to me that perhaps Josh can implement
a command line switch to turn on command line numbering.
That
It is actually still in my mailbox to be added to TODO when I get up to it.
---
Alvaro Herrera wrote:
Joshua D. Drake wrote:
On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Tom Lane
Alvaro Herrera wrote:
I will claim this for now. I will let it go if I can't get at least
something productive done on it by end of January.
Now that the embargo period seems to be over, I think it would be a good
time to add it to the TODO list. Also, I'd modify the idea slightly to
Tom Lane wrote:
Richard Troy [EMAIL PROTECTED] writes:
... it occurs to me that perhaps Josh can implement
a command line switch to turn on command line numbering.
That would solve the problem I have with changing \s. I think a psql
\set variable (comparable to ON_ERROR_STOP and friends)
Alvaro Herrera wrote:
Tom Lane wrote:
Richard Troy [EMAIL PROTECTED] writes:
... it occurs to me that perhaps Josh can implement
a command line switch to turn on command line numbering.
That would solve the problem I have with changing \s. I think a psql
\set variable (comparable
On Fri, 2006-12-29 at 20:59 -0500, Bruce Momjian wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
Richard Troy [EMAIL PROTECTED] writes:
... it occurs to me that perhaps Josh can implement
a command line switch to turn on command line numbering.
That would solve the problem I have
I wrote:
Actually, looking at the comments for ucs_wcwidth() in wchar.c, it seems
that this is already accounted for in the dsplen output: characters
for which -1 is returned are control characters, characters for which
0 is returned should be printed as-is and counted as zero width. So the
On Wed, Dec 27, 2006 at 02:49:41PM -0500, Tom Lane wrote:
I've applied the attached patch to fix this, but not being much of a
user of languages that have combining characters, I can't test it very
well. Please check out the behavior and see if you like it.
Looks good so far. I've tested
On 19/12/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
I think the problem Mario is really trying to solve is quitting at
psql's Password: prompt. Ctrl-C is ignored at that point apparently.
SIGQUIT (thus Ctrl-\ in most people's setup) does it but it also dumps
core.
yes, that is true and
On 19/12/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
This normally a SIGQUIT, and on my machine at least the default action for
that is a core dump. Perhaps you need to say what you are trying to do and
why.
I'd like to help :-) I wanted to avoid a core dumped but you told
me that's a
Mario wrote:
I'd like to help :-) I wanted to avoid a core dumped but you told
me that's a normal thing for a SIGQUIT signal.
Did you try running `ulimit -c 0` first? That should do what you want -
prevent generation of the dump file.
Regards, Philip.
--
Philip Yarra
Senior Software
Mario wrote:
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
This isn't a bug.
On 20/12/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Mario wrote:
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
Mario wrote:
On 20/12/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Mario wrote:
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is supposed to dump core. Ulimit settings can suppress
generation of core
Mario [EMAIL PROTECTED] writes:
On 20/12/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
This isn't a bug. It's working as designed.
Even if you get a core dumped every time you press CTRL+\ ? why?
That's what C-\ does. Try it with any other program:
$ sleep 1
Quit (core dumped)
On Wed, 20 Dec 2006, Philip Yarra wrote:
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is supposed to dump core. Ulimit
Jeremy Drake wrote:
On Wed, 20 Dec 2006, Philip Yarra wrote:
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We change libpq from time to time. Besides, how many DBs are there that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
expect lots of surprise.
Um, but how many DB names have an = in
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
We change libpq from time to time. Besides, how many DBs are there that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
expect lots of surprise.
Um, but how many DB names have an = in them at all?
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql conn:service=sname user=uname
Perhaps this should be implemented in libpq, not at the psql level?
Otherwise you're
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql conn:service=sname user=uname
Perhaps this should be implemented in libpq, not at the psql
On Tue, Dec 12, 2006 at 05:44:07PM -0500, Andrew Dunstan wrote:
Now I look at fe-connect.c more closely, I'm tempted just to try parsing
the dbname param as a conninfo string, and if it doesn't work fall back
on a plain dbname. I could greatly reduce the chance of following the
failure path
Martijn van Oosterhout kleptog@svana.org writes:
Does that mean that:
psql -d service=myservice
should Just Work(tm)? That would be nice.
Even more to the point,
psql service=myservice
which is why we want to overload dbname rather than any of the other
PQsetdbLogin parameters for
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Does that mean that:
psql -d service=myservice
should Just Work(tm)? That would be nice.
Even more to the point,
psql service=myservice
which is why we want to overload dbname rather than any of the other
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there was
anything wrong with your syntax (eg, misspelled
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there
Casey Duncan wrote:
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a
On Dec 12, 2006, at 5:16 PM, Andrew Dunstan wrote:
Casey Duncan wrote:
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get
Casey Duncan wrote:
I was speaking from and end-user point of view, but I see your point.
It's certainly attractive to just patch libpq and be done. However,
that does have the side-effect of implicitly propagating the behavior
to all libpg client software. That may be more unpleasantly
Andrew Dunstan [EMAIL PROTECTED] writes:
We change libpq from time to time. Besides, how many DBs are there that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
expect lots of surprise.
Um, but how many DB names have an = in them at all?
Basically what this proposal is
Tom Lane wrote:
We change libpq from time to time. Besides, how many DBs are there
that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I
don't
expect lots of surprise.
Um, but how many DB names have an = in them at all?
Basically what this proposal is about is migrating
Andrew Dunstan [EMAIL PROTECTED] writes:
I have just noticed that there does not seem to be a psql command line
switch to specify a pg_service.conf name to connect to. I know we can
use a PGSERVICE environment setting instead, but I think we should have
a command line switch too. Small 8.3
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have just noticed that there does not seem to be a psql
command line switch to specify a pg_service.conf name
to connect to. I know we can use a PGSERVICE environment
setting instead, but I think we should have
a command line
On Wed, Sep 27, 2006 at 04:54:35PM +0200, Albe Laurenz wrote:
I think that both would be nice. Indeed, I wanted to suggest
a switch for PGSERVICE myself.
It some point I was wondering about using the @ symbol. If you have a
service entry called testserver, you could do:
psql @testserver
But
On Wed, Sep 27, 2006 at 10:23:13AM -0400, Andrew Dunstan wrote:
I have just noticed that there does not seem to be a psql command
line switch to specify a pg_service.conf name to connect to. I know
we can use a PGSERVICE environment setting instead, but I think we
should have a command line
On Fri, Aug 11, 2006 at 10:58:12PM -0400, Tom Lane wrote:
Currently, psql does not show the command completion tag if it gets a
PGRES_TUPLES_OK result. This means you won't see the tag for a command
with RETURNING, eg
regression=# insert into int8_tbl values(1,2),(3,4);
INSERT 0 2
On May 16, 2006, at 14:17 , Tom Lane wrote:
[1] Mostly. There's the infamous continued-string-literal
construct...
Are you referring to this?
est=# SELECT 'foo''bar'; -- invalid
ERROR: syntax error at or near 'bar' at character 17
LINE 1: SELECT 'foo''bar';
Michael Glaesemann [EMAIL PROTECTED] writes:
On May 16, 2006, at 14:17 , Tom Lane wrote:
[1] Mostly. There's the infamous continued-string-literal
construct...
Are you referring to this?
^
test=# SELECT 'foo'
test-# 'bar'; -- valid
Yeah. It seems weird that a
Joshua D. Drake wrote:
Hello,
I was dinking around wand came across something that may (or may not be
useful).
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
E.g;
postgres=# select * from foo; update foo set bar = 'baz';
Joshua D. Drake [EMAIL PROTECTED] writes:
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
regards, tom lane
---(end of
Joshua D. Drake [EMAIL PROTECTED] wrote
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
E.g;
postgres=# select * from foo; update foo set bar = 'baz'; delete from
bing;
Would be a single transaction ? The begin/commit would be
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What if single line statements that were seperated by ; within psql were
implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
I wouldn't assume that it would be a default feature of course. Perhaps
On May 16, 2006, at 13:42 , Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
What if single line statements that were seperated by ; within
psql were implicitly within a transaction?
Seems like this would risk breaking a lot of scripts.
I wouldn't assume
Michael Glaesemann [EMAIL PROTECTED] writes:
What use case are you envisioning? Just saving ... *counts ... 14
keystrokes in this case? (I'm not saying there *isn't* a use case. I
just don't see a big benefit here.)
Quite aside from the compatibility and how-useful-is-it-really
arguments,
Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
What use case are you envisioning? Just saving ... *counts ... 14
keystrokes in this case? (I'm not saying there *isn't* a use case. I
just don't see a big benefit here.)
Quite aside from the compatibility and
Tom Lane wrote:
Quite aside from the compatibility and how-useful-is-it-really
arguments, I think this'd be a bad idea in the abstract. SQL is not one
of those languages that assigns semantic significance to the shape of
whitespace [1]. We should NOT introduce any such concept into psql,
On Mon, Apr 10, 2006 at 10:02:25PM -0400, Bruce Momjian wrote:
The patch wasn't ignored. It is just that I never got to applying it yet.
Neil's patch vs. psql supercedes this :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
The patch wasn't ignored. It is just that I never got to applying it yet.
---
David Fetter wrote:
On Sat, Mar 11, 2006 at 12:15:08PM -0500, Tom Lane wrote:
Markus Bertheau [EMAIL PROTECTED] writes:
Why is it trying
On Mon, 3 Apr 2006 06:13 am, Neil Conway wrote:
I've committed a patch to HEAD that should improve this behavior. Let me
know if the current behavior is still unsatisfactory.
Yes, thanks, it fixes the stuff that bugged me:
[EMAIL PROTECTED] pgsql]$ psql -p5434 -dpyarra
[snip opening car chase]
On Thu, 2006-03-30 at 11:20 +1000, Philip Yarra wrote:
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as expected
when postmaster is listening on non-default port.
I've committed a patch to HEAD that should improve this behavior. Let me
know if the current behavior is still
Philip Yarra [EMAIL PROTECTED] writes:
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as
expected
Yeah, there were complaints about this already. I think the problem was
introduced by this patch:
2006-02-11 21:54 momjian
* doc/src/sgml/ref/psql-ref.sgml,
On Wed, Mar 29, 2006 at 10:19:51PM -0500, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as
expected
Yeah, there were complaints about this already. I think the problem was
introduced by this patch:
I sent one
On Mar 11, 2006, at 19:13 , Markus Bertheau wrote:
Why is it trying to use 5432? Am I missing something? Is that the
expected behaviour?
Was your 8.2devel install built with the default port of 5432? (i.e.,
do you need to set the port to 5433 in postgresql.conf or at server
start? It
On Mar 11, 2006, at 19:36 , Markus Bertheau wrote:
I'm pretty sure you didn't have to specify the port with \c again in
earlier versions - so this is a regression, and a confusing one imho
You couldn't connect to another host from the same psql session, so
including the port wasn't even an
On Saturday 11 March 2006 05:51, Michael Glaesemann wrote:
On Mar 11, 2006, at 19:36 , Markus Bertheau wrote:
I'm pretty sure you didn't have to specify the port with \c again in
earlier versions - so this is a regression, and a confusing one imho
You couldn't connect to another host from
Markus Bertheau [EMAIL PROTECTED] writes:
Why is it trying to use 5432? Am I missing something? Is that the
expected behaviour?
Michael Fuhr hinted that
http://archives.postgresql.org/pgsql-committers/2006-02/msg00139.php
may be the cause of that.
Confirmed here: \c drops the previous port
On Sat, Mar 11, 2006 at 12:15:08PM -0500, Tom Lane wrote:
Markus Bertheau [EMAIL PROTECTED] writes:
Why is it trying to use 5432? Am I missing something? Is that the
expected behaviour?
Michael Fuhr hinted that
http://archives.postgresql.org/pgsql-committers/2006-02/msg00139.php
may
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
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
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
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
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
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
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
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
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
Tom Lane [EMAIL PROTECTED] 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
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
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
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
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
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
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,
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.
Robert Treat [EMAIL PROTECTED] 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
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.
-Original Message-
From: [EMAIL PROTECTED] 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
-Original Message-
From: [EMAIL PROTECTED] 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
-Original Message-
From: [EMAIL PROTECTED] 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
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
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,
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 [EMAIL PROTECTED]|). Which would help people a lot.
Yes we should, at least for Windows -
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 [EMAIL PROTECTED]|). Which would help people a lot.
Yes we should,
Tom Lane [EMAIL PROTECTED] writes:
Robert Treat [EMAIL PROTECTED] 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
Greg Stark said:
Tom Lane [EMAIL PROTECTED] writes:
Robert Treat [EMAIL PROTECTED] 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
On Mon, 2 Jan 2006 16:27:48 -0600 (CST)
Andrew Dunstan [EMAIL PROTECTED] 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 |
Andrew Dunstan [EMAIL PROTECTED] 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
Magnus Hagander [EMAIL PROTECTED] 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.
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] 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
On Monday 02 January 2006 18:21, Andrew Dunstan wrote:
Tom Lane said:
Andrew Dunstan [EMAIL PROTECTED] 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,
Andrew Dunstan [EMAIL PROTECTED] 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
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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
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
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
1201 - 1300 of 1586 matches
Mail list logo
