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

Copy/paste from psql - was: Changing the continuation-line prompt in psql?

From: Alastair Turner <bell(at)ctrlf5(dot)co(dot)za>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Christopher Browne <cbbrowne(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Copy/paste from psql - was: Changing the continuation-line prompt in psql?
Date: 2011-04-30 08:10:40
Message-ID: BANLkTime8Yn-pvy55j5a-_g4ssdJj0SYMQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Apr 29, 2011 at 8:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
>>> The "bike shedding" that I'd rather have would involve enclosing
>>> prompts with /* comments */ so that cut'n'paste could be expected to
>>> generate output that could run, without further editing, in another
>>> psql session.  Mind you, whenever I have configured such, I have been
>>> unhappy at how wide that makes the prompt and at the loss of screen
>>> space.
>
>> I would second this precise interest. It really annoys me more often
>> than anything else that when I try to copy/paste an sql query I need
>> to copy each line one by one. It would be different from MySql but I
>> think it would be even clearer to the user:
>
>> postgres=> select 1,
>> /*line 2:*/        2,
>> /*line 3:*/        3;
>
> This looks promising until you stop to think about either string
> literals or /* comment blocks being continued across lines ...
>
The copy paste problem also frustrates me, maybe modifying the prompt
isn't an effective answer though.

Extending the history command (\s) sounds more promising
\s- for a reverse ordered history
\s[n] for the last n or n-from-last-th (\s1 different from \p in that
it shows the last completed query not the one in progress)

and most importantly showing full history through a less-style
interface like large result sets rather than in the flow of psql

Does that sound like a workable answer?

Regards,
Bell.

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-04-30 13:18:45
Subject: Re: Predicate locking
Previous:From: Vlad ArkhipovDate: 2011-04-30 03:24:09
Subject: Re: Predicate locking

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