Skip site navigation (1) Skip section navigation (2)

Re: Re [HACKERS]: Still not happy with psql's multiline history behavior

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Re [HACKERS]: Still not happy with psql's multiline history behavior
Date: 2006-06-04 04:45:55
Message-ID: 200606040445.k544jtY13486@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Sergey E. Koposov wrote:
> Hello,
> 
> I'm sending the patch fixing the \r bug:

Funny, I just applied a simpler fix for the \r bug.  Please review it. 
Thanks.

I am confused by the \e bug.  I just tried 8.1.X and it seems to behave
the same as CVS HEAD.  What exactly should it do?

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


> 
> On Wed, 31 May 2006, Tom Lane wrote:
> 
> > The example that seriously sucks is:
> >
> > regression=# select foo ...
> > regression-# \r
> > Query buffer reset (cleared).
> > now control-P brings back:
> > regression=# select foo ...
> > \r
> 
> In my fix the currently-written query is completely erased if \r is
> invoked. I think that's the most logic behavior.
> So, the example of work:
> 
> wsdb=# select 1;
>   ?column?
> ----------
>          1
> (1 row)
> 
> wsdb=# select
> wsdb-# \r
> Query buffer reset (cleared).
> wsdb=#
> Control-P now brings back:
> wsdb=# \r
> 
> Another Control-P brings back:
> wsdb=# select 1;
> 
> 
> > Also, \e is seriously broken: after you edit the text and exit the
> > editor, the text is not reloaded into the visible display (although it
> > does seem to still be "behind the scenes" somewhere).
> 
> For that part, I currently do not see the possible fix, and I don't even 
> think that it should be fixed, because there with current multi-line 
> implementation there is no need for that.
> 
> For example, when we do
> wsdb=# select 1+
> wsdb-#
> And press Control-P , the string "select 1+" is not in the history, and 
> there is no need for that.
> 
> And in the case of \e editing, if in the external editor we have typed 
> the incomplete query like "select 1+", the situation will be exactly the 
> same and for the same reason...
> 
> So, I don't think, that this require fixing. In principal, probably it is 
> possible to fix that in a different way:
> Suppose we executed the \e command and in the external editor we typed 
> "select 1 +". And after the exit from the editor, psql produce
> wsdb=# select 1 + 
> (and put cursor in the end of the line).
> 
> That can be reasonable (I'm not sure that it's possible to do that with 
> readline, but should be).
> But I would consider that as a new feature (probably not very useful), not 
> as a bug fix.
> 
> Regards,
>  	Sergey
> 
> *******************************************************************
> Sergey E. Koposov
> Max Planck Institute for Astronomy/Sternberg Astronomical Institute
> Tel: +49-6221-528-349      Web: http://lnfm1.sai.msu.ru/~math
> E-mail: math(at)sai(dot)msu(dot)ru

Content-Description: 

[ Attachment, skipping... ]

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Sergey E. KoposovDate: 2006-06-04 04:57:12
Subject: Re: Re [HACKERS]: Still not happy with psql's multiline history
Previous:From: Bruce MomjianDate: 2006-06-04 04:36:38
Subject: Re: [HACKERS] Still not happy with psql's multiline history behavior

pgsql-patches by date

Next:From: Sergey E. KoposovDate: 2006-06-04 04:57:12
Subject: Re: Re [HACKERS]: Still not happy with psql's multiline history
Previous:From: Bruce MomjianDate: 2006-06-04 04:36:38
Subject: Re: [HACKERS] Still not happy with psql's multiline history behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group