Hi,

Is there any way of making the 'up' arrow retrieve all of the last multiline
query, instead of just the last line?  It's really annoying working with
large multiline queries at the moment...

Chris


Wed, 8 Jan 2003 14:55:54 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
psql and readline
On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
> Hi,
>
> Is there any way of making the 'up' arrow retrieve all of the last
> multiline query, instead of just the last line?  It's really annoying
> working with large multiline queries at the moment...

Not that I know of, but you can use \e to edit the query in your 
favourite editor.

Ian Barwick
barwick@gmx.net

Wed, 8 Jan 2003 10:53:51 +0100
Ian Barwick <barwick@gmx.net>
Re: psql and readline
On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
> > Hi,
> >
> > Is there any way of making the 'up' arrow retrieve all of the last
> > multiline query, instead of just the last line?  It's really annoying
> > working with large multiline queries at the moment...
> 
> Not that I know of, but you can use \e to edit the query in your 
> favourite editor.

Sure. But \e puts "\e" into history, instead of the query itself :(

-- 
Fduch M. Pravking

Wed, 8 Jan 2003 15:02:20 +0300
"Alexander M. Pravking" <fduch@antar.bryansk.ru>
Re: psql and readline
On Wednesday 08 January 2003 13:02, Alexander M. Pravking wrote:
> On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
> > > Hi,
> > >
> > > Is there any way of making the 'up' arrow retrieve all of the last
> > > multiline query, instead of just the last line?  It's really annoying
> > > working with large multiline queries at the moment...
> >
> > Not that I know of, but you can use \e to edit the query in your
> > favourite editor.
>
> Sure. But \e puts "\e" into history, instead of the query itself :(

Yes, but the query will remain in the psql query buffer until a different
SQL query (i.e. not a slash command) is executed. Until then
you can reedit and / or reexecute the query (with \g) as long as you like.

Ian Barwick
barwick@gmx.net

Wed, 8 Jan 2003 13:14:58 +0100
Ian Barwick <barwick@gmx.net>
Re: psql and readline
On Wed, 8 Jan 2003, Christopher Kings-Lynne wrote:

> Hi,
> 
> Is there any way of making the 'up' arrow retrieve all of the last multiline
> query, instead of just the last line?  It's really annoying working with
> large multiline queries at the moment...

When you say multiline do you mean this:

template1=$ select * from
template1-$ abc a
template1-$ where a.id=1;

or a situation where the query text exceeds the terminal width and wraps
to the next line? If the latter, see if horizontal-scroll-mode is set to
off in your ~/.inputrc. If the former, that sounds kind of elaborate and
to wrong way to do things.

> 
> Chris

Gavin



Wed, 8 Jan 2003 23:17:38 +1100 (EST)
Gavin Sherry <swm@linuxworld.com.au>
Re: psql and readline
> > Is there any way of making the 'up' arrow retrieve all of the last multiline
> > query, instead of just the last line?  It's really annoying working with
> > large multiline queries at the moment...
>
> When you say multiline do you mean this:
>
> template1=$ select * from
> template1-$ abc a
> template1-$ where a.id=1;

Yes.  Basically, the classic example is when I copy and paste large
queries or DDL from my SQL files in CVS.  It's a real pain.

Chris



Wed, 8 Jan 2003 22:30:02 +0800 (WST)
Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: psql and readline
"Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
>> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
>>> Is there any way of making the 'up' arrow retrieve all of the last
>>> multiline query, instead of just the last line?  It's really annoying
>>> working with large multiline queries at the moment...
>> 
>> Not that I know of, but you can use \e to edit the query in your 
>> favourite editor.

> Sure. But \e puts "\e" into history, instead of the query itself :(

Hm, so it does.  It seems like the edited query should go into history,
at least when you execute it.  Peter, is this fixable?

			regards, tom lane

Wed, 08 Jan 2003 12:19:03 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql and readline 
Tom Lane wrote:
> "Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> >> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne wrote:
> >>> Is there any way of making the 'up' arrow retrieve all of the last
> >>> multiline query, instead of just the last line?  It's really annoying
> >>> working with large multiline queries at the moment...
> >> 
> >> Not that I know of, but you can use \e to edit the query in your 
> >> favourite editor.
> 
> > Sure. But \e puts "\e" into history, instead of the query itself :(
> 
> Hm, so it does.  It seems like the edited query should go into history,
> at least when you execute it.  Peter, is this fixable?

Wow, that would be a nifty trick, though they really did type \e and not
the query the pulled in from the editor.

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

Wed, 8 Jan 2003 12:28:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline
On 8 Jan 2003 at 12:28, Bruce Momjian wrote:

> Tom Lane wrote:
> > "Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > >> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne
> > >> wrote:
> > >>> Is there any way of making the 'up' arrow retrieve all of the
> > >>> last multiline query, instead of just the last line?  It's
> > >>> really annoying working with large multiline queries at the
> > >>> moment...
> > >> 
> > >> Not that I know of, but you can use \e to edit the query in your
> > >> favourite editor.
> > 
> > > Sure. But \e puts "\e" into history, instead of the query itself
> > > :(
> > 
> > Hm, so it does.  It seems like the edited query should go into
> > history, at least when you execute it.  Peter, is this fixable?
> 
> Wow, that would be a nifty trick, though they really did type \e and
> not the query the pulled in from the editor.

What about those of us who want to use \e repeatedly?  Will that be 
in the history buffer?
-- 
Dan Langille : http://www.langille.org/


Wed, 08 Jan 2003 12:33:12 -0500
"Dan Langille" <dan@langille.org>
Re: psql and readline
On Wed, 8 Jan 2003, Dan Langille wrote:

> On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> 
> > Tom Lane wrote:
> > > "Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> > > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > > >> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne
> > > >> wrote:
> > > >>> Is there any way of making the 'up' arrow retrieve all of the
> > > >>> last multiline query, instead of just the last line?  It's
> > > >>> really annoying working with large multiline queries at the
> > > >>> moment...
> > > >> 
> > > >> Not that I know of, but you can use \e to edit the query in your
> > > >> favourite editor.
> > > 
> > > > Sure. But \e puts "\e" into history, instead of the query itself
> > > > :(
> > > 
> > > Hm, so it does.  It seems like the edited query should go into
> > > history, at least when you execute it.  Peter, is this fixable?
> > 
> > Wow, that would be a nifty trick, though they really did type \e and
> > not the query the pulled in from the editor.
> 
> What about those of us who want to use \e repeatedly?  Will that be 
> in the history buffer?

The number of times I've cursed things over the years, I would have 
thought having the edited query in the history would be more useful than 
\e - the latter is only three key presses any how ;-)

Peter

-- 
Peter Mount
peter@retep.org.uk
http://www.retep.org.uk/
 Tel/Fax: +44 (0) 1622 749439
  Mobile: +44 (0) 7903 155887
  US Fax: 1 435 304 5165
US Voice: 1 435 304 5165



Thu, 9 Jan 2003 13:45:45 +0000 (UTC)
Peter Mount <peter@retep.org.uk>
Re: psql and readline
On Thu, 2003-01-09 at 08:45, Peter Mount wrote:
> On Wed, 8 Jan 2003, Dan Langille wrote:
> > On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > "Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> > > > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > > > >> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne
> > > > >> wrote:
> > > > >>> Is there any way of making the 'up' arrow retrieve all of the
> > > > >>> last multiline query, instead of just the last line?  It's
> > > > >>> really annoying working with large multiline queries at the
> > > > >>> moment...
> > > > >> 
> > > > >> Not that I know of, but you can use \e to edit the query in your
> > > > >> favourite editor.
> > > > 
> > > > > Sure. But \e puts "\e" into history, instead of the query itself
> > > > > :(
> > > > 
> > > > Hm, so it does.  It seems like the edited query should go into
> > > > history, at least when you execute it.  Peter, is this fixable?
> > > 
> > > Wow, that would be a nifty trick, though they really did type \e and
> > > not the query the pulled in from the editor.
> > 
> > What about those of us who want to use \e repeatedly?  Will that be 
> > in the history buffer?
> 
> The number of times I've cursed things over the years, I would have 
> thought having the edited query in the history would be more useful than 
> \e - the latter is only three key presses any how ;-)
> 

Or if the query could be appended after the \e, it would only be a quick
"double-up" to get back to the \e.

Robert Treat



09 Jan 2003 09:15:34 -0500
Robert Treat <xzilla@users.sourceforge.net>
Re: psql and readline
On 9 Jan 2003 at 9:15, Robert Treat wrote:

> On Thu, 2003-01-09 at 08:45, Peter Mount wrote:
> > On Wed, 8 Jan 2003, Dan Langille wrote:
> > > On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> > > > Tom Lane wrote:
> > > > > "Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> > > > > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > > > > >> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne
> > > > > >> wrote:
> > > > > >>> Is there any way of making the 'up' arrow retrieve all of
> > > > > >>> the last multiline query, instead of just the last line? 
> > > > > >>> It's really annoying working with large multiline queries
> > > > > >>> at the moment...
> > > > > >> 
> > > > > >> Not that I know of, but you can use \e to edit the query in
> > > > > >> your favourite editor.
> > > > > 
> > > > > > Sure. But \e puts "\e" into history, instead of the query
> > > > > > itself :(
> > > > > 
> > > > > Hm, so it does.  It seems like the edited query should go into
> > > > > history, at least when you execute it.  Peter, is this
> > > > > fixable?
> > > > 
> > > > Wow, that would be a nifty trick, though they really did type \e
> > > > and not the query the pulled in from the editor.
> > > 
> > > What about those of us who want to use \e repeatedly?  Will that
> > > be in the history buffer?
> > 
> > The number of times I've cursed things over the years, I would have
> > thought having the edited query in the history would be more useful
> > than \e - the latter is only three key presses any how ;-)
> > 
> 
> Or if the query could be appended after the \e, it would only be a
> quick "double-up" to get back to the \e.

As this is changing existing behaviour, I think adding an optional  
switch to revert to the old behaviour is a good idea.
-- 
Dan Langille : http://www.langille.org/


Thu, 09 Jan 2003 09:33:21 -0500
"Dan Langille" <dan@langille.org>
Re: psql and readline
How do I know the clock on the machine you're
running on will be set to the same time as the 
clock on the database? how postgre handle this
internal?

thanks.

johnl

Thu, 9 Jan 2003 08:39:33 -0600
"John Liu" <johnl@synthesys.com>
clock sync
Dan Langille wrote:
<snip>
> As this is changing existing behaviour, I think adding an optional  
> switch to revert to the old behaviour is a good idea.

Two thoughts:

a) Is it possible to change the behavior of the history as we're 
discussing?  Haven't heard Peter's response to this.

b) Do we really want to go to the effort of adding a switch to revert to 
previous behaviour for something like this?  It's almost definitely a 
win to have \e commands appear in the history, and seems a bit to 
trivial for adding switches for.

?

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Fri, 10 Jan 2003 01:16:49 +1030
Justin Clift <justin@postgresql.org>
Re: psql and readline
Justin Clift wrote:
> b) Do we really want to go to the effort of adding a switch to revert to 
> previous behaviour for something like this?  It's almost definitely a 
> win to have \e commands appear in the history, and seems a bit to 
> trivial for adding switches for.

Bad wording there... "\e commands" is meant to mean "commands created 
through using \e"


-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Fri, 10 Jan 2003 01:20:03 +1030
Justin Clift <justin@postgresql.org>
Re: psql and readline
resent with my real mail address...

On 9 Jan 2003 at 13:45, Peter Mount wrote:

> On Wed, 8 Jan 2003, Dan Langille wrote:
> 
> > On 8 Jan 2003 at 12:28, Bruce Momjian wrote:
> > 
> > > Tom Lane wrote:
> > > > "Alexander M. Pravking" <fduch@antar.bryansk.ru> writes:
> > > > > On Wed, Jan 08, 2003 at 10:53:51AM +0100, Ian Barwick wrote:
> > > > >> On Wednesday 08 January 2003 07:55, Christopher Kings-Lynne
> > > > >> wrote:
> > > > >>> Is there any way of making the 'up' arrow retrieve all of the
> > > > >>> last multiline query, instead of just the last line?  It's really
> > > > >>> annoying working with large multiline queries at the moment...
> > > > >> 
> > > > >> Not that I know of, but you can use \e to edit the query in your
> > > > >> favourite editor.
> > > > 
> > > > > Sure. But \e puts "\e" into history, instead of the query itself :(
> > > > 
> > > > Hm, so it does.  It seems like the edited query should go into
> > > > history, at least when you execute it.  Peter, is this fixable?
> > > 
> > > Wow, that would be a nifty trick, though they really did type \e and
> > > not the query the pulled in from the editor.
> > 
> > What about those of us who want to use \e repeatedly?  Will that be in
> > the history buffer?
> 
> The number of times I've cursed things over the years, I would have 
> thought having the edited query in the history would be more useful than \e
> - the latter is only three key presses any how ;-)

It is easier to edit things within an editor than within the command line, 
especially if using very long complex statements involving 8 or 9 tables 
and nested/outer JOINS.
-- 
Dan Langille : http://www.langille.org/


Thu, 09 Jan 2003 10:02:42 -0500
"Dan Langille" <dan@langille.org>
Re: psql and readline
Justin Clift wrote:
> Dan Langille wrote:
> <snip>
> > As this is changing existing behaviour, I think adding an optional  
> > switch to revert to the old behaviour is a good idea.
> 
> Two thoughts:
> 
> a) Is it possible to change the behavior of the history as we're 
> discussing?  Haven't heard Peter's response to this.
> 
> b) Do we really want to go to the effort of adding a switch to revert to 
> previous behaviour for something like this?  It's almost definitely a 
> win to have \e commands appear in the history, and seems a bit to 
> trivial for adding switches for.

Let's suppose I am writing a query, and then I do \e to edit the query,
and I exit the editor and return to psql.  Suppose I decide I want to
reedit, so I up arrow.  I would expect to get \e, not the query I just
edited, no?

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

Thu, 9 Jan 2003 10:05:15 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline
Bruce Momjian wrote:
<snip>
> Let's suppose I am writing a query, and then I do \e to edit the query,
> and I exit the editor and return to psql.  Suppose I decide I want to
> reedit, so I up arrow.  I would expect to get \e, not the query I just
> edited, no?

Wouldn't it depend on how this gets implemented?

Maybe least negative impact approach (suggested already): If the "large 
command that was edited" is put in the command history before the \e, 
then both are available and there is no big change from "expected 
behaviour".

i.e. one up arrow get the previous \e, and a second up arrow would bring 
up the command that was worked upon.

?

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Fri, 10 Jan 2003 01:42:29 +1030
Justin Clift <justin@postgresql.org>
Re: psql and readline
Justin Clift wrote:
> Bruce Momjian wrote:
> <snip>
> > Let's suppose I am writing a query, and then I do \e to edit the query,
> > and I exit the editor and return to psql.  Suppose I decide I want to
> > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > edited, no?
> 
> Wouldn't it depend on how this gets implemented?
> 
> Maybe least negative impact approach (suggested already): If the "large 
> command that was edited" is put in the command history before the \e, 
> then both are available and there is no big change from "expected 
> behaviour".
> 
> i.e. one up arrow get the previous \e, and a second up arrow would bring 
> up the command that was worked upon.

Makese sense.  However, it still has the shock factor of displaying a
huge query, which is usually what is involved when using the editor.  I
don't feel strongly either way --- I am just pointing out the issue.

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

Thu, 9 Jan 2003 10:13:14 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline
On Fri, 10 Jan 2003, Justin Clift wrote:

> Bruce Momjian wrote:
> <snip>
> > Let's suppose I am writing a query, and then I do \e to edit the query,
> > and I exit the editor and return to psql.  Suppose I decide I want to
> > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > edited, no?
> 
> Wouldn't it depend on how this gets implemented?
> 
> Maybe least negative impact approach (suggested already): If the "large 
> command that was edited" is put in the command history before the \e, 
> then both are available and there is no big change from "expected 
> behaviour".
> 
> i.e. one up arrow get the previous \e, and a second up arrow would bring 
> up the command that was worked upon.

Yes, that would then not confuse things too much when someone expects \e 
as that's the last thing they typed.

The main benefit I can see is when you have entered a large query, then a 
smaller one (or another \ command), and want to re-run the large query. 
Currently you could use the terminal's history and copy/paste it, but if 
you edited the query with \e then that doesn't work (or worse if the 
terminal doesn't support it, or it's scrolled off the top of the buffer).

Peter

-- 
Peter Mount
peter@retep.org.uk
http://www.retep.org.uk/
 Tel/Fax: +44 (0) 1622 749439
  Mobile: +44 (0) 7903 155887
  US Fax: 1 435 304 5165
US Voice: 1 435 304 5165



Thu, 9 Jan 2003 15:22:46 +0000 (UTC)
Peter Mount <peter@retep.org.uk>
Re: psql and readline
On 9 Jan 2003 at 10:13, Bruce Momjian wrote:

> Justin Clift wrote:
> > Bruce Momjian wrote:
> > <snip>
> > > Let's suppose I am writing a query, and then I do \e to edit the
> > > query, and I exit the editor and return to psql.  Suppose I decide
> > > I want to reedit, so I up arrow.  I would expect to get \e, not
> > > the query I just edited, no?
> > 
> > Wouldn't it depend on how this gets implemented?
> > 
> > Maybe least negative impact approach (suggested already): If the
> > "large command that was edited" is put in the command history before
> > the \e, then both are available and there is no big change from
> > "expected behaviour".
> > 
> > i.e. one up arrow get the previous \e, and a second up arrow would
> > bring up the command that was worked upon.
> 
> Makese sense.  However, it still has the shock factor of displaying a
> huge query, which is usually what is involved when using the editor. 

Which is a good indicator that a way to turn it off is a good idea.
-- 
Dan Langille : http://www.langille.org/


Thu, 09 Jan 2003 10:24:29 -0500
"Dan Langille" <dan@langille.org>
Re: psql and readline
On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
> Bruce Momjian wrote:
> <snip>
> > Let's suppose I am writing a query, and then I do \e to edit the query,
> > and I exit the editor and return to psql.  Suppose I decide I want to
> > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > edited, no?
> 
> Wouldn't it depend on how this gets implemented?
> 
> Maybe least negative impact approach (suggested already): If the "large 
> command that was edited" is put in the command history before the \e, 
> then both are available and there is no big change from "expected 
> behaviour".

We could always create a new command that edits a query buffer rather
than file

\e FILENAME

\E QUERY BUFFER


So, history of:
\E SELECT .......

Selecting this would fire off an editor based on the query to the right
of the command, much as \e FILENAME opens an editor based on the file to
the right of the command.
-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
09 Jan 2003 10:25:30 -0500
Rod Taylor <rbt@rbt.ca>
Re: psql and readline
On Thu, 09 Jan 2003 10:13:14 EST, the world broke into rejoicing as
Bruce Momjian <pgman@candle.pha.pa.us>  said:
> Justin Clift wrote:
> > Bruce Momjian wrote:
> > <snip>
> > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > and I exit the editor and return to psql.  Suppose I decide I want to
> > > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > > edited, no?
> > 
> > Wouldn't it depend on how this gets implemented?
> > 
> > Maybe least negative impact approach (suggested already): If the "large 
> > command that was edited" is put in the command history before the \e, 
> > then both are available and there is no big change from "expected 
> > behaviour".
> > 
> > i.e. one up arrow get the previous \e, and a second up arrow would bring 
> > up the command that was worked upon.
> 
> Makese sense.  However, it still has the shock factor of displaying a
> huge query, which is usually what is involved when using the editor.  I
> don't feel strongly either way --- I am just pointing out the issue.

There's a surprise available in both directions.

If the previous command was "use external editor on query," then it
seems unreasonable to forcibly expand that out.  If I edited the
query, it's more than likely that I'd like to edit it again.

But I'd like to have a way to expand the query so that I /can/ see it
in full form.  It would be unfortunate for the /only/ way to get at
the query would be to \e it.

Perhaps the answer is to have some form of "\expand" directive that
replaces itself with the query's contents, or, better still, which
doesn't actually /execute/ the query, but rather pulls in the query
from outside and pushes it into the command line.  The /next/ time you
hit enter, the query will get executed.
--
output = reverse("moc.enworbbc@" "enworbbc")
http://cbbrowne.com/info/linux.html
Eagles may soar, free and proud, but weasels never get sucked into jet
engines.

Thu, 09 Jan 2003 10:34:59 -0500
cbbrowne@cbbrowne.com
Re: psql and readline 
On 9 Jan 2003, Rod Taylor wrote:

> On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
> > Bruce Momjian wrote:
> > <snip>
> > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > and I exit the editor and return to psql.  Suppose I decide I want to
> > > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > > edited, no?
> > 
> > Wouldn't it depend on how this gets implemented?
> > 
> > Maybe least negative impact approach (suggested already): If the "large 
> > command that was edited" is put in the command history before the \e, 
> > then both are available and there is no big change from "expected 
> > behaviour".
> 
> We could always create a new command that edits a query buffer rather
> than file
> 
> \e FILENAME
> 
> \E QUERY BUFFER
> 
> 
> So, history of:
> \E SELECT .......
> 
> Selecting this would fire off an editor based on the query to the right
> of the command, much as \e FILENAME opens an editor based on the file to
> the right of the command.

That's a possible one, but the only problem I can see is if the user uses 
\e on it's own (ie not read in a file).

Do we then place just \e or \E QUERY BUFFER into the history?

Peter

-- 
Peter Mount
peter@retep.org.uk
http://www.retep.org.uk/
 Tel/Fax: +44 (0) 1622 749439
  Mobile: +44 (0) 7903 155887
  US Fax: 1 435 304 5165
US Voice: 1 435 304 5165



Thu, 9 Jan 2003 15:42:15 +0000 (UTC)
Peter Mount <peter@retep.org.uk>
Re: psql and readline
On Thu, 09 Jan 2003 08:39:33 CST, the world broke into rejoicing as
"John Liu" <johnl@synthesys.com>  said:
> How do I know the clock on the machine you're
> running on will be set to the same time as the 
> clock on the database? how postgre handle this
> internal?

You'll know because you already run NTP on all your servers to make
sure that they are synchronizing times, right?

PostgreSQL doesn't include time synchronization software because NTP
does that perfectly well, just as it doesn't include a job scheduler
because cron does that perfectly well.

... And if your machines have substantially different times, different
sorts of issues will emerge depending on what you're doing.

- If the "client" sends over literal current time stamps based on what
time it thinks it is, that may differ from what time the server thinks
it is.

- If you do that, and then try looking in PostgreSQL logs, based on
the "client's" timestamps, you'll look at the wrong times, and get
confused.

- If the client passes in things that select now(), timestamps will be
returned based on when the /server/ thinks it is.  Which should leave
the database consistent, but which might confuse the client if it has
logic that processes that time, and gets deranged because now()
differs massively from what time it thinks it is.

The case where you'll get /badly/ bitten is if you're trying to do
replication with servers that have substantially differing ideas as to
what time it is.

But what you /should/ do is run NTP on all your machines, thus getting
rid of the problem.  <http://www.ntp.org/>
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/ntp.html
Rules  of the  Evil  Overlord #30.   "All  bumbling conjurers,  clumsy
squires, no-talent  bards, and  cowardly thieves in  the land  will be
preemptively put  to death.  My foes  will surely give  up and abandon
their quest if they have no source of comic relief."
<http://www.eviloverlord.com/>

Thu, 09 Jan 2003 10:51:26 -0500
cbbrowne@cbbrowne.com
Re: clock sync 
On Thu, 2003-01-09 at 10:42, Peter Mount wrote:
> On 9 Jan 2003, Rod Taylor wrote:
> 
> > On Thu, 2003-01-09 at 10:12, Justin Clift wrote:
> > > Bruce Momjian wrote:
> > > <snip>
> > > > Let's suppose I am writing a query, and then I do \e to edit the query,
> > > > and I exit the editor and return to psql.  Suppose I decide I want to
> > > > reedit, so I up arrow.  I would expect to get \e, not the query I just
> > > > edited, no?
> > > 
> > > Wouldn't it depend on how this gets implemented?
> > > 
> > > Maybe least negative impact approach (suggested already): If the "large 
> > > command that was edited" is put in the command history before the \e, 
> > > then both are available and there is no big change from "expected 
> > > behaviour".
> > 
> > We could always create a new command that edits a query buffer rather
> > than file
> > 
> > \e FILENAME
> > 
> > \E QUERY BUFFER
> > 
> > 
> > So, history of:
> > \E SELECT .......
> > 
> > Selecting this would fire off an editor based on the query to the right
> > of the command, much as \e FILENAME opens an editor based on the file to
> > the right of the command.
> 
> That's a possible one, but the only problem I can see is if the user uses 
> \e on it's own (ie not read in a file).
> 
> Do we then place just \e or \E QUERY BUFFER into the history?

I'd tend to switch it to store \E QUERY BUFFER in the history, and
possibly remove the ability to use \e by itself -- or make \E FILENAME
and \e QUERY BUFFER.

Since the use of \e isn't likely to be used in a programmatic
(automated) way, but only by users who could quickly figure it out.

-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc
09 Jan 2003 10:56:56 -0500
Rod Taylor <rbt@rbt.ca>
Re: psql and readline
Rod Taylor wrote:
> I'd tend to switch it to store \E QUERY BUFFER in the history, and
> possibly remove the ability to use \e by itself -- or make \E FILENAME
> and \e QUERY BUFFER.
> 
> Since the use of \e isn't likely to be used in a programmatic
> (automated) way, but only by users who could quickly figure it out.

I don't think it makes sense to remove \e just to add history
functionality.

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

Thu, 9 Jan 2003 11:01:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Rod Taylor wrote:
>> Since the use of \e isn't likely to be used in a programmatic
>> (automated) way, but only by users who could quickly figure it out.

> I don't think it makes sense to remove \e just to add history
> functionality.

Indeed, that would defeat the purpose completely, wouldn't it?

If you are using the "\e file" form then the contents of the file
already provide history, of a sort (at least, you can get back the
immediately preceding version of the query when you edit it).
The case I find interesting is where you're using plain "\e" to
re-edit a query interactively.  If this query never gets into the
history buffer then you're lost: you won't be able to pull it back
for re-editing a second time.

Perhaps more to the point: without the "\e" form, \e does not offer a
solution to the original poster's request, and so we're back to square
one.

			regards, tom lane

Thu, 09 Jan 2003 11:18:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql and readline 
On Thu, 9 Jan 2003, Bruce Momjian wrote:

> Rod Taylor wrote:
> > I'd tend to switch it to store \E QUERY BUFFER in the history, and
> > possibly remove the ability to use \e by itself -- or make \E FILENAME
> > and \e QUERY BUFFER.
> > 
> > Since the use of \e isn't likely to be used in a programmatic
> > (automated) way, but only by users who could quickly figure it out.
> 
> I don't think it makes sense to remove \e just to add history
> functionality.

I agree. Also more people would type \e than they would \E. Also they are
used to having \e available. Adding the functionality to the history is
useful, but we shouldn't change things too much.

I currently think that if \e is typed on it's own, then \E QUERY BUFFER 
goes into the history. Keep the existing behaviour of \e FILENAME the 
same. I'd doubt that a user would type \E QUERY BUFFER themselves often 
(if at all).

Peter

-- 
Peter Mount
peter@retep.org.uk
http://www.retep.org.uk/
 Tel/Fax: +44 (0) 1622 749439
  Mobile: +44 (0) 7903 155887
  US Fax: 1 435 304 5165
US Voice: 1 435 304 5165



Thu, 9 Jan 2003 16:23:29 +0000 (UTC)
Peter Mount <peter@retep.org.uk>
Re: psql and readline
Hi guys,

As a curiosity thought, would it be possible to do something like:

\ep

Where this tells psql to get the query in the history prior to the \e, 
and edit it interactively?

:-)

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi


Fri, 10 Jan 2003 02:53:56 +1030
Justin Clift <justin@postgresql.org>
Re: psql and readline
On Wed, 2003-01-08 at 15:30, Christopher Kings-Lynne wrote:
> > > Is there any way of making the 'up' arrow retrieve all of the last multiline
> > > query, instead of just the last line?  It's really annoying working with
> > > large multiline queries at the moment...

You could use ledit, piped with psql works great. I use it with sqlplus
from Oracle too, adds me readline functions sqlplus doesnt have:

Under Debian GNU/Linux:

$ apt-cache search ledit   
ledit - A line editor for interactive programs.

It has some OpenCAML dependencies, beware.

After:

$ ledit | psql yourdatabase

...my 2 cents 

-- 
Jean-Paul ARGUDO
DBA PostgreSQL, MySQL, Oracle, Ingres
Membre de l'April			http://www.april.org


09 Jan 2003 20:21:14 +0100
Jean-Paul ARGUDO <jean-paul.argudo@wanadoo.fr>
Re: psql and readline
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> The case I find interesting is where you're using plain "\e" to
>> re-edit a query interactively.  If this query never gets into the
>> history buffer then you're lost: you won't be able to pull it back
>> for re-editing a second time.

> If you call \e again immediately then you edit the previous command.

But it'd be nice to have some *history*, ie be able to pull back older
commands.

			regards, tom lane

Thu, 09 Jan 2003 16:43:27 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql and readline 
Christopher Kings-Lynne writes:

> Is there any way of making the 'up' arrow retrieve all of the last multiline
> query, instead of just the last line?

There is nothing technical that should prevent you from implementing it.
But you need to come up with a reasonable system to keep the history
straight if meta commands are mixed with multiline commands, such as

select *
\x
from foo;

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 9 Jan 2003 22:49:33 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql and readline
Tom Lane writes:

> The case I find interesting is where you're using plain "\e" to
> re-edit a query interactively.  If this query never gets into the
> history buffer then you're lost: you won't be able to pull it back
> for re-editing a second time.

If you call \e again immediately then you edit the previous command.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 9 Jan 2003 22:49:42 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql and readline 
On Thu, Jan 09, 2003 at 10:49:33PM +0100, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
> 
> > Is there any way of making the 'up' arrow retrieve all of the last multiline
> > query, instead of just the last line?
> 
> There is nothing technical that should prevent you from implementing it.
> But you need to come up with a reasonable system to keep the history
> straight if meta commands are mixed with multiline commands, such as
> 
> select *
> \x
> from foo;

Peter, what do you think about pushing the query buffer onto the history
stack at execution time, any time it's a multiline query? That way,
after the above sequence, you'd have:

(1) select *
(2) \x
(3) from foo;
(4) select * 
    from foo;

Yeah, this wastes a history slot, but it does solve the problem. It's also
dead simple to code. ;-)

BTW, the behavior in bash for multiline interactive entered commands
is to concatenate them into a single line and dump them in the history,
replacing the individual parts.  The individual parts are in the history
while you're at the secondary prompt, then go away after execution. In
psql, we'd probably just lose interstitial metacommands.

Ross

Thu, 9 Jan 2003 16:46:20 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: psql and readline
On Thu, 9 Jan 2003, Peter Eisentraut wrote:

> Tom Lane writes:
> 
> > The case I find interesting is where you're using plain "\e" to
> > re-edit a query interactively.  If this query never gets into the
> > history buffer then you're lost: you won't be able to pull it back
> > for re-editing a second time.
> 
> If you call \e again immediately then you edit the previous command.

Yes, but it's not always the last command you want :-(

Peter

-- 
Peter Mount
peter@retep.org.uk
http://www.retep.org.uk/
 Tel/Fax: +44 (0) 1622 749439
  Mobile: +44 (0) 7903 155887
  US Fax: 1 435 304 5165
US Voice: 1 435 304 5165



Fri, 10 Jan 2003 07:15:34 +0000 (UTC)
Peter Mount <peter@retep.org.uk>
Re: psql and readline 
On Fri, Jan 10, 2003 at 07:15:34AM +0000, Peter Mount wrote:
> On Thu, 9 Jan 2003, Peter Eisentraut wrote:
> 
> > Tom Lane writes:
> > 
> > > The case I find interesting is where you're using plain "\e" to
> > > re-edit a query interactively.  If this query never gets into the
> > > history buffer then you're lost: you won't be able to pull it back
> > > for re-editing a second time.
> > 
> > If you call \e again immediately then you edit the previous command.
> 
> Yes, but it's not always the last command you want :-(

I already posted a one-line patch to implement this, but it doesn't
seem to hve come through to the list. Here it is inline, instead of as
an attachment:


Index: src/bin/psql/command.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.84
diff -u -r1.84 command.c
--- src/bin/psql/command.c	2002/10/23 19:23:56	1.84
+++ src/bin/psql/command.c	2003/01/09 22:18:49
@@ -1639,6 +1639,7 @@
 				error = true;
 			}
 
+			replace_history_entry(where_history(),query_buf->data,NULL);
 			fclose(stream);
 		}

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

Ross

Fri, 10 Jan 2003 01:49:05 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: psql and readline
Ross J. Reedstrom writes:

> I already posted a one-line patch to implement this, but it doesn't
> seem to hve come through to the list. Here it is inline, instead of as
> an attachment:

We need this to work without readline as well.  (Of course there won't be
any history, but it needs to compile.)

-- 
Peter Eisentraut   peter_e@gmx.net


Fri, 10 Jan 2003 23:02:55 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql and readline
On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
> 
> > I already posted a one-line patch to implement this, but it doesn't
> > seem to hve come through to the list. Here it is inline, instead of as
> > an attachment:
> 
> We need this to work without readline as well.  (Of course there won't be
> any history, but it needs to compile.)

<blush> Even after slogging my way through the nesting #ifdefs for readline
and win32, I forgot! Let's make that a three line patch, then.


Index: src/bin/psql/command.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.84
diff -u -r1.84 command.c
--- src/bin/psql/command.c	2002/10/23 19:23:56	1.84
+++ src/bin/psql/command.c	2003/01/10 22:06:07
@@ -1639,6 +1639,9 @@
 				error = true;
 			}
 
+#ifdef USE_READLINE
+			replace_history_entry(where_history(),query_buf->data,NULL);
+#endif
 			fclose(stream);
 		}
 
Ross

Fri, 10 Jan 2003 16:07:16 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: psql and readline
I've been following this thread, and I thought this might be a good 
place and time to throw in a few additional feature requests.

What about expanding the history capabilities of psql's history command 
(\s) to include something more bash/tcsh-like?  For example:

    !insert
       -- execute the last command that began with "insert"

    !23
       -- execute item #23 in my history

The above would require \s to output history index numbers.  Might also 
be cool if it would (optionally) truncate each line at the console 
width, so it would be a little easier to read.

And what about some kind of switch to tell psql to combine multi-line 
commands into 1.  So if I type a big select on 5 lines, after executing 
it, it appears as 1 entry in my history.  Say something like \ss for 
"history Single" and \sv for "history Verbatim" (or whatever).

Thanks for your time.

eric


Tue, 14 Jan 2003 19:24:08 -0500
Eric B.Ridge <ebr@tcdi.com>
Re: psql and readline
Eric B.Ridge writes:

> What about expanding the history capabilities of psql's history command
> (\s) to include something more bash/tcsh-like?  For example:
>     !insert
>        -- execute the last command that began with "insert"
>     !23
>        -- execute item #23 in my history

If you peruse the documentation of the readline and history libraries you
should find that those features already exist.  For example, you can use
C-r and C-s to search through the history.  AFAIK, bash just uses readline
as is, so anything that works there should work for psql as well.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 16 Jan 2003 00:45:22 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql and readline

Your patch has been added to the PostgreSQL unapplied patches list at:

	http://momjian.postgresql.org/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

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


Ross J. Reedstrom wrote:
> On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote:
> > Ross J. Reedstrom writes:
> > 
> > > I already posted a one-line patch to implement this, but it doesn't
> > > seem to hve come through to the list. Here it is inline, instead of as
> > > an attachment:
> > 
> > We need this to work without readline as well.  (Of course there won't be
> > any history, but it needs to compile.)
> 
> <blush> Even after slogging my way through the nesting #ifdefs for readline
> and win32, I forgot! Let's make that a three line patch, then.
> 
> 
> Index: src/bin/psql/command.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
> retrieving revision 1.84
> diff -u -r1.84 command.c
> --- src/bin/psql/command.c	2002/10/23 19:23:56	1.84
> +++ src/bin/psql/command.c	2003/01/10 22:06:07
> @@ -1639,6 +1639,9 @@
>  				error = true;
>  			}
>  
> +#ifdef USE_READLINE
> +			replace_history_entry(where_history(),query_buf->data,NULL);
> +#endif
>  			fclose(stream);
>  		}
>  
> Ross
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

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

Mon, 3 Feb 2003 07:31:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline

Patch applied.  Thanks.

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


Ross J. Reedstrom wrote:
> On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote:
> > Ross J. Reedstrom writes:
> > 
> > > I already posted a one-line patch to implement this, but it doesn't
> > > seem to hve come through to the list. Here it is inline, instead of as
> > > an attachment:
> > 
> > We need this to work without readline as well.  (Of course there won't be
> > any history, but it needs to compile.)
> 
> <blush> Even after slogging my way through the nesting #ifdefs for readline
> and win32, I forgot! Let's make that a three line patch, then.
> 
> 
> Index: src/bin/psql/command.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
> retrieving revision 1.84
> diff -u -r1.84 command.c
> --- src/bin/psql/command.c	2002/10/23 19:23:56	1.84
> +++ src/bin/psql/command.c	2003/01/10 22:06:07
> @@ -1639,6 +1639,9 @@
>  				error = true;
>  			}
>  
> +#ifdef USE_READLINE
> +			replace_history_entry(where_history(),query_buf->data,NULL);
> +#endif
>  			fclose(stream);
>  		}
>  
> Ross
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

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

Wed, 12 Feb 2003 23:08:16 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline
The sad thing is that my readline wrapper for libedit doesn't wrap
replace_history_entry, so I could use readline up until now, the tests
for readline succeed as the functions tested for exist, but

command.o: In function `do_edit':
/usr/src/local/pgsql/src/bin/psql/command.c:1652: undefined reference to `replace_history_entry'

ho hum..

Patrick


On Wed, Feb 12, 2003 at 11:08:16PM -0500, Bruce Momjian wrote:
> 
> Patch applied.  Thanks.
> 
> ---------------------------------------------------------------------------
> 
> 
> Ross J. Reedstrom wrote:
> > On Fri, Jan 10, 2003 at 11:02:55PM +0100, Peter Eisentraut wrote:
> > > Ross J. Reedstrom writes:
> > > 
> > > > I already posted a one-line patch to implement this, but it doesn't
> > > > seem to hve come through to the list. Here it is inline, instead of as
> > > > an attachment:
> > > 
> > > We need this to work without readline as well.  (Of course there won't be
> > > any history, but it needs to compile.)
> > 
> > <blush> Even after slogging my way through the nesting #ifdefs for readline
> > and win32, I forgot! Let's make that a three line patch, then.
> > 
> > 
> > Index: src/bin/psql/command.c
> > ===================================================================
> > RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
> > retrieving revision 1.84
> > diff -u -r1.84 command.c
> > --- src/bin/psql/command.c	2002/10/23 19:23:56	1.84
> > +++ src/bin/psql/command.c	2003/01/10 22:06:07
> > @@ -1639,6 +1639,9 @@
> >  				error = true;
> >  			}
> >  
> > +#ifdef USE_READLINE
> > +			replace_history_entry(where_history(),query_buf->data,NULL);
> > +#endif
> >  			fclose(stream);
> >  		}
> >  
> > Ross
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> >     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> > 
> 
> -- 
>   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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Thu, 13 Feb 2003 12:50:30 +0000
Patrick Welche <prlw1@newn.cam.ac.uk>
Re: psql and readline
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> The sad thing is that my readline wrapper for libedit doesn't wrap
> replace_history_entry,

Well, is that a bug in your wrapper?  Or must we add a configure test
for the presence of replace_history_entry()?

			regards, tom lane

Thu, 13 Feb 2003 10:25:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql and readline 
On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
> Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> > The sad thing is that my readline wrapper for libedit doesn't wrap
> > replace_history_entry,
> 
> Well, is that a bug in your wrapper?  Or must we add a configure test
> for the presence of replace_history_entry()?

Good question. Easiest for now for me would be add a configure test. Long
term libedit needs tweeking... In fact for now, I just comment out the call
the replace_history_entry, as I am more than happy with the rest of the
readline behaviour (as implemented in libedit).

Patrick

Fri, 14 Feb 2003 16:00:05 +0000
Patrick Welche <prlw1@newn.cam.ac.uk>
Re: psql and readline
Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
>> Well, is that a bug in your wrapper?  Or must we add a configure test
>> for the presence of replace_history_entry()?

> Good question. Easiest for now for me would be add a configure test.

Okay with me --- Ross, can you handle that?

			regards, tom lane

Fri, 14 Feb 2003 11:32:02 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql and readline 
On Sat, Feb 15, 2003 at 03:10:19PM -0600, Ross J. Reedstrom wrote:
> On Fri, Feb 14, 2003 at 11:32:02AM -0500, Tom Lane wrote:
> > Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> > > On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
> > >> Well, is that a bug in your wrapper?  Or must we add a configure test
> > >> for the presence of replace_history_entry()?
> > 
> > > Good question. Easiest for now for me would be add a configure test.
> > 
> > Okay with me --- Ross, can you handle that?

O.K., I found the 'editline' wrapper around 'libedit' that provides
a subset of readline functionality, and used that for testing. On my
Debian Linux systems, editline installs readline compatability headers
(readline.h, history.h) into /usr/include/editline/, so I added tests
for those into configure.in, and src/include/pg_config.h.in, and usage
in src/bin/psql/input.h

I added a test for replace_history_entry() to configure.in, and usage
of it to src/bin/psql/command.c. As you may recall, the original purpose
of this patch was to deal with the interaction of '\e' with the history
buffer.  I implemented replacing the '\e' entry in the buffer with the
query as returned by the edit session and sent to the backend. If the
replace_history_entry function is missing, I now just push the edited
entry onto the history stack, leaving the '\e' in place as well.

Tested on systems with readline, editline, and --without-readline.

Since the patch has now grown to 25 lines, I've posted it over to PATCHES.

Ross

Sat, 15 Feb 2003 20:21:51 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: psql and readline
On Sat, Feb 15, 2003 at 03:10:19PM -0600, Ross J. Reedstrom wrote:
> On Fri, Feb 14, 2003 at 11:32:02AM -0500, Tom Lane wrote:
> > Patrick Welche <prlw1@newn.cam.ac.uk> writes:
> > > On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
> > >> Well, is that a bug in your wrapper?  Or must we add a configure test
> > >> for the presence of replace_history_entry()?
> > 
> > > Good question. Easiest for now for me would be add a configure test.
> > 
> > Okay with me --- Ross, can you handle that?
> 
> I'll take a crack at it. Testing will be a problem, since all my machines
> have libreadline installed, but I've got one I can probably pull it off
> of. Patrick, is 'your libedit wrapper' your personal code, or something
> standard on some set of systems (e.g. *BSD) ?

It's the standard NetBSD libedit which comes with built-in readline emulation,
it's just that replace_history_entry isn't one of the emulated functions.
({read,write,add}_history() are included)

> Ross "one line patches always grow" Reedstrom

:-)

I'm of course very happy to test the growing patch!

Cheers,

Patrick

Sun, 16 Feb 2003 17:29:34 +0000
Patrick Welche <prlw1@newn.cam.ac.uk>
Re: psql and readline
Ross J. Reedstrom writes:

> O.K., I found the 'editline' wrapper around 'libedit' that provides
> a subset of readline functionality, and used that for testing. On my
> Debian Linux systems, editline installs readline compatability headers
> (readline.h, history.h) into /usr/include/editline/, so I added tests
> for those into configure.in, and src/include/pg_config.h.in, and usage
> in src/bin/psql/input.h

I don't think this is what we were out for.  We've certainly been running
with libedit for a long time without anyone ever mentioning
/usr/include/editline.  I suggest this part is taken out.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 17 Feb 2003 00:05:20 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql and readline
On Mon, Feb 17, 2003 at 12:05:20AM +0100, Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
> 
> I don't think this is what we were out for.  We've certainly been running
> with libedit for a long time without anyone ever mentioning
> /usr/include/editline.  I suggest this part is taken out.

Well, I found a set of systems that install libedit (and editline) in that
location (i.e. Debian Linux). I couldn't test on the standard version of
that system without either this, or hacking a symlink into /usr/include.

Yes, BSD systems that install libedit directly in /usr/include (or into
readline), like Patrick's,  don't need it, but mine do. Is there some
reason we _shouldn't_ support this configuration?

Ross

Sun, 16 Feb 2003 18:23:34 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: psql and readline
Ross J. Reedstrom writes:

> Yes, BSD systems that install libedit directly in /usr/include (or into
> readline), like Patrick's,  don't need it, but mine do. Is there some
> reason we _shouldn't_ support this configuration?

I don't like adding code to support every configuration that someone
dreamed up but no one actually needs.  Readline installs the header files
into <readline/readline.h> and if someone thinks they can change that they
deserve to pay the price.  The configure script is already slow enough
without this.

-- 
Peter Eisentraut   peter_e@gmx.net


Wed, 19 Feb 2003 00:03:44 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql and readline
On Wed, Feb 19, 2003 at 12:03:44AM +0100, Peter Eisentraut wrote:
> Ross J. Reedstrom writes:
> 
> > Yes, BSD systems that install libedit directly in /usr/include (or into
> > readline), like Patrick's,  don't need it, but mine do. Is there some
> > reason we _shouldn't_ support this configuration?
> 
> I don't like adding code to support every configuration that someone
> dreamed up but no one actually needs.  Readline installs the header files
> into <readline/readline.h> and if someone thinks they can change that they
> deserve to pay the price.  The configure script is already slow enough
> without this.

Hmm, isn't this exactly what configure is  for? To find out where this
particular system installs all the bits and pieces? Note that even without
the test for editline/readline.h, the existing configure looks in two
placesi for readline functionality, so doesn't match your comment,
above. As for 'someone changing that' paying the price, I think it's
reasonable for an incomplete compatability library to install into a
different location: if it claims to be readline/readline.h, it better
support the entire API, in my book.

Regardless of all of the above, I'm willing to let this part go. Note that
I can no longer easily test libedit functionality in that case, however.
I leave it up to Bruce (or whomever applies the patch)

Ross

Tue, 18 Feb 2003 17:55:45 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: psql and readline
Ross J. Reedstrom wrote:
> On Wed, Feb 19, 2003 at 12:03:44AM +0100, Peter Eisentraut wrote:
> > Ross J. Reedstrom writes:
> > 
> > > Yes, BSD systems that install libedit directly in /usr/include (or into
> > > readline), like Patrick's,  don't need it, but mine do. Is there some
> > > reason we _shouldn't_ support this configuration?
> > 
> > I don't like adding code to support every configuration that someone
> > dreamed up but no one actually needs.  Readline installs the header files
> > into <readline/readline.h> and if someone thinks they can change that they
> > deserve to pay the price.  The configure script is already slow enough
> > without this.
> 
> Hmm, isn't this exactly what configure is  for? To find out where this
> particular system installs all the bits and pieces? Note that even without
> the test for editline/readline.h, the existing configure looks in two
> placesi for readline functionality, so doesn't match your comment,
> above. As for 'someone changing that' paying the price, I think it's
> reasonable for an incomplete compatability library to install into a
> different location: if it claims to be readline/readline.h, it better
> support the entire API, in my book.
> 
> Regardless of all of the above, I'm willing to let this part go. Note that
> I can no longer easily test libedit functionality in that case, however.
> I leave it up to Bruce (or whomever applies the patch)

Configure is for such tests --- you are right, and we already test two
places.  I doubt there is any measurable change in testing 10 locations.
Just allowing you to test libedit is enough to justify the addition.

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

Tue, 18 Feb 2003 20:03:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: psql and readline
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Ross J. Reedstrom wrote:
>> On Wed, Feb 19, 2003 at 12:03:44AM +0100, Peter Eisentraut wrote:
>>> I don't like adding code to support every configuration that someone
>>> dreamed up but no one actually needs.
>>
>> Hmm, isn't this exactly what configure is  for?

> Configure is for such tests --- you are right, and we already test two
> places.

I have to side with Ross also.  Configure makes many tests that are
designed for situations much less common than his.  I don't see
the reason for refusing to accommodate this one.

(Not that I've looked at the details of the patch, mind you.  But in
principle it seems reasonable.)

			regards, tom lane

Wed, 19 Feb 2003 10:30:06 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: psql and readline 