Changing the continuation-line prompt in psql?

On Fri, Apr 29, 2011 at 17:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Over at
http://archives.postgresql.org/pgsql-novice/2011-04/msg00102.php
there's an interesting thread about a novice who forgot to put a
semicolon at the end of his SQL commands, and what psql might do to be
a little more friendly at the beginning of the learning curve.  We see
similar complaints every so often, so it seems like something that would
be worth doing something about.  Several ideas were mentioned, but the
one that seemed to get the most approval was to make psql's PROMPT2
(the continuation line prompt) more visibly different from PROMPT1.
I've got to agree that the difference between

       postgres=>
       postgres->

is on the subtle side.  Two different possible changes were suggested:

* Drop the database name from PROMPT2, so you see

       postgres=>
       ->

Definite -1 on that option - your query no longer lines up, and if you
then for example open it in an editor, indentation changes.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

On Fri, Apr 29, 2011 at 17:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:

... Two different possible changes were suggested:

* Drop the database name from PROMPT2, so you see

postgres=>
->

Definite -1 on that option - your query no longer lines up, and if you
then for example open it in an editor, indentation changes.

Yeah, there is that. I just went over to see what the competition does
here, and it looks like this:

mysql> select 2
-> +2
-> + 'foo
'> bar
'> baz'
-> "quoted
"> identifier"
-> /*
/*> comment */
-> ;

AFAICT the initial prompt is always "mysql> ", so they don't have to
think hard about how many spaces to insert to make it line up. But
we could certainly invent a prompt escape that means "as many spaces
as there are characters in the current DB name". (Or maybe we should
try to generalize that idea, so you could get similar behavior for
custom prompts involving usernames etc?)

regards, tom lane

On Apr 29, 2011, at 8:22 AM, Tom Lane wrote:

AFAICT the initial prompt is always "mysql> ", so they don't have to
think hard about how many spaces to insert to make it line up. But
we could certainly invent a prompt escape that means "as many spaces
as there are characters in the current DB name". (Or maybe we should
try to generalize that idea, so you could get similar behavior for
custom prompts involving usernames etc?)

+1 I like this idea, so the prompt might by default be

postgres=>
+>

Best,

David

Excerpts from David E. Wheeler's message of vie abr 29 13:04:35 -0300 2011:

On Apr 29, 2011, at 8:22 AM, Tom Lane wrote:

AFAICT the initial prompt is always "mysql> ", so they don't have to
think hard about how many spaces to insert to make it line up. But
we could certainly invent a prompt escape that means "as many spaces
as there are characters in the current DB name". (Or maybe we should
try to generalize that idea, so you could get similar behavior for
custom prompts involving usernames etc?)

+1 I like this idea, so the prompt might by default be

postgres=>
+>

That was my immediate thought after seeing Magnus' response too.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Fri, Apr 29, 2011 at 12:17 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

Excerpts from David E. Wheeler's message of vie abr 29 13:04:35 -0300 2011:

On Apr 29, 2011, at 8:22 AM, Tom Lane wrote:

AFAICT the initial prompt is always "mysql> ", so they don't have to
think hard about how many spaces to insert to make it line up.  But
we could certainly invent a prompt escape that means "as many spaces
as there are characters in the current DB name".  (Or maybe we should
try to generalize that idea, so you could get similar behavior for
custom prompts involving usernames etc?)

+1 I like this idea, so the prompt might by default be

    postgres=>
            +>

That's certainly a reasonable sort of start.

It seems like pretty serious bikeshedding to try to come up with an
operator to express "do as many of character X as the length of
variable $FOO". I know people have been hacking on zsh and Bash to do
wacky things like that - I somewhat doubt that we really want to go
too far down that road. (I'd be about equally excited about
integrating an APL into psql. Of course, I'm watching
<https://github.com/kevinlawler/kona&gt;, which is an ASCII-ized APL
clone, so that mightn't be the thing I'd MOST vigorously argue against
;-).)

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'm not totally appalled at the thought of subsequent lines not being
perfectly aligned with the first one - frequently, the first line of a
multiline query is differently indented or has different proper policy
(e.g. - CREATE OR REPLACE FUNCTION *can* safely differ from the body
of the function).

I think I could readily live with PROMPT2=" +>", all in all.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

* Christopher Browne (cbbrowne@gmail.com) wrote:

It seems like pretty serious bikeshedding to try to come up with an
operator to express "do as many of character X as the length of
variable $FOO".

How about "pad with spaces to line up prompt", or such? In general, I
like the idea of having spaces there instead of the db name.

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.

Uhm.. With the above, perhaps "--%Z+>", which would generate:

postgres=>
-- +>

etc.

Thanks,

Stephen

Christopher Browne <cbbrowne@gmail.com> writes:

Excerpts from David E. Wheeler's message of vie abr 29 13:04:35 -0300 2011:

+1 I like this idea, so the prompt might by default be

postgres=>
+>

That's certainly a reasonable sort of start.

It seems like pretty serious bikeshedding to try to come up with an
operator to express "do as many of character X as the length of
variable $FOO".

The idea that I was considering was to define the prompt sequence "% X"
to mean "as many spaces as %X would produce characters", for any X.

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.

Well, you can do that today, whenever you need it, by modifying the
values of PROMPT1 and PROMPT2. The loss-of-screen-space issue makes me
think it'd not be very reasonable to make it the default.

I'm not totally appalled at the thought of subsequent lines not being
perfectly aligned with the first one - frequently, the first line of a
multiline query is differently indented or has different proper policy
(e.g. - CREATE OR REPLACE FUNCTION *can* safely differ from the body
of the function).

It wasn't bothering me either initially, but the argument about the
command looking different when you suck it into an editor with \e
has some credibility.

regards, tom lane

On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne <cbbrowne@gmail.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;
?column? | ?column? | ?column?
----------+----------+----------
1 | 2 | 3
(1 row)

--
greg

* Stephen Frost (sfrost@snowman.net) wrote:

Uhm.. With the above, perhaps "--%Z+>", which would generate:

postgres=>
-- +>

yah, obviously not going to work. :) However, it wouldn't be impossible
to have psql recognize and strip "--<spaces>+> " if/when it's seen
starting a new line, if we set it up such that it's always the same..
Could be optional anyway, perhaps configurable as a regexp.

Anyhow, just some thoughts.

Thanks,

Stephen

2011/4/29 Greg Stark <gsstark@mit.edu>:

On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne <cbbrowne@gmail.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;
 ?column? | ?column? | ?column?
----------+----------+----------
       1 |        2 |        3
(1 row)

+1

Pavel

Greg Stark <gsstark@mit.edu> writes:

On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne <cbbrowne@gmail.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 ...

regards, tom lane

On Fri, Apr 29, 2011 at 02:10:19PM -0400, Stephen Frost wrote:

* Stephen Frost (sfrost@snowman.net) wrote:

Uhm.. With the above, perhaps "--%Z+>", which would generate:

postgres=>
-- +>

yah, obviously not going to work. :) However, it wouldn't be impossible
to have psql recognize and strip "--<spaces>+> " if/when it's seen
starting a new line, if we set it up such that it's always the same..
Could be optional anyway, perhaps configurable as a regexp.

Anyhow, just some thoughts.

Thanks,

Stephen

+1 to have psql strip a configurable beginning of line sequence.

Regards,
Ken

Tom Lane <tgl@sss.pgh.pa.us> writes:

It wasn't bothering me either initially, but the argument about the
command looking different when you suck it into an editor with \e
has some credibility.

It still do not bother me the least, I much prefer PROMPT2 to be +>.

With emacs you use M-d then a rectangular cut (C-x r k runs the command
kill-rectangle), as any user of it might know. I don't suppose it's
that more a problem with other people editors of choice, or certainly
they would switch.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Excerpts from Dimitri Fontaine's message of vie abr 29 16:37:37 -0300 2011:

Tom Lane <tgl@sss.pgh.pa.us> writes:

It wasn't bothering me either initially, but the argument about the
command looking different when you suck it into an editor with \e
has some credibility.

It still do not bother me the least, I much prefer PROMPT2 to be +>.

With emacs you use M-d then a rectangular cut (C-x r k runs the command
kill-rectangle), as any user of it might know. I don't suppose it's
that more a problem with other people editors of choice, or certainly
they would switch.

Not a problem in Vim either, just use a visual block (Ctrl-V). With the
leading spaces to line up, a rectangular region works great; if there's
no lineup, you have to cut the first line separately which is a bit
annoying.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On fre, 2011-04-29 at 19:06 +0100, Greg Stark wrote:

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;
?column? | ?column? | ?column?
----------+----------+----------
1 | 2 | 3
(1 row)

How about just making the continuation prompts empty then?

Peter Eisentraut <peter_e@gmx.net> writes:

How about just making the continuation prompts empty then?

Personally I'd be very annoyed to lose the %R marker (the "are you in
a string literal?" flag). So I think that that's not a good default.
Of course, anyone who *is* that concerned about copy&paste cases can
set PROMPT2 to empty today.

regards, tom lane

I'll bet someone a fancy drink at a conference that this thread goes to at least 100 posts.

Let the bikeshedding begin!

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco

Joshua Berkus <josh@agliodbs.com> writes:

I'll bet someone a fancy drink at a conference that this thread goes to at least 100 posts.

Of course, if we all are to argue about this bet… :)

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Dimitri,

I'll bet someone a fancy drink at a conference that this thread goes
to at least 100 posts.

Of course, if we all are to argue about this bet… :)

Darn! You've uncovered by sinister plan. Foiled again!

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco