Thread: psql and readline
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
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
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
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
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
> > 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
"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
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, Pennsylvania19073
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/
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
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
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/
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
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
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
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/
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, Pennsylvania19073
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
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, Pennsylvania19073
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
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/
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
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.
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
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/>
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
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, Pennsylvania19073
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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, Pennsylvania19073
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, Pennsylvania19073
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)
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
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
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
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
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
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
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
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
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, Pennsylvania19073
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
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