Re: psql: recall previous command?
От | Thomas F.O'Connell |
---|---|
Тема | Re: psql: recall previous command? |
Дата | |
Msg-id | e37264a0db39a20b3e1a069ec66765cb@sitening.com обсуждение исходный текст |
Ответ на | psql: recall previous command? (Neil Conway <neilc@samurai.com>) |
Список | pgsql-hackers |
One interesting artifact of using \e to edit a multi-line command is that the same command is then treated as a single-line command in subsequent up-arrow or Ctrl-P attempts. I use this frequently to achieve a similar effect to what you're after. The one downside is that if you leave the psql session, it's returned to multi-line format in the psql history. -tfo -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005d On Feb 21, 2005, at 10:26 PM, Neil Conway wrote: > Is there a way to recall the previous command in psql? Obviously, "up > arrow" or Ctrl-P using readline and the default readline bindings is > close, but it recalls the previous _line_ of input. That is not at all > the same thing in the case of a multiple line command, for example. > > If there is no way at present, I think there should be. Using "up > arrow" > is quite annoying when dealing with multiple line SQL statements. > > Two issues: > > - how to handle slash commands? Slash commands and SQL statements can > be intermixed: > > neilc=# select 1 \timing > Timing is off. > neilc-# ; > ?column? > ---------- > 1 > (1 row) > > So I'm not quite sure what the right behavior here is. We could always > just ignore slash commands (the command would "recall the previous SQL > statement") -- since few slash commands are multi-line, I don't think > that would be too bad. > > - when a multiple-line command is recalled, how should it be presented > in the psql input buffer? Perhaps we could strip newlines from > recalled command text, so that the recalled command would fit on a > single line. That would mean the recalled command would look somewhat > different than how the user typed it, although of course the semantics > of the query should be the same. Any better ideas? > > -Neil > > > ---------------------------(end of > broadcast)--------------------------- > TIP 8: explain analyze is your friend
В списке pgsql-hackers по дате отправления: