Обсуждение: Changing the continuation-line prompt in psql?
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=> -> * Change the continuation-line marker from "-" to "+", so you see postgres=> postgres+> We could do either or both of these. If we did both it'd look like postgres=> +> "+" seems like an obviously more mnemonic marker than "-" for additional lines, in addition to being more visually distinct. Dropping the DB name would change the length of the prompt, which even the most clueless noob ought to recognize as a cue about change of state, but maybe that would be too distracting for anyone past the noob stage. One possibly pleasant aspect of dropping the DB name is that it would only require a change in the default value of the PROMPT2 variable, so anyone who really hated it could undo it by setting a custom value for that. Changing the marker would require changing the behavior of the "%R" prompt escape sequence. (I suppose we could leave %R alone and invent a new escape that behaves just slightly differently, but that's probably carrying backwards compatibility too far.) Also, of course you can experiment with the effects of dropping the DB name by doing \set PROMPT2 '%R%# ' After doing a bit of experimentation myself, I think that changing the marker is a clear win but I'm less sure about dropping the DB name. I could probably get used to that after awhile, but it's a bit jarring for a longtime user. On the plus side, there's more screen space for the long command you're typing. Thoughts? regards, tom lane
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>, 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
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
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 > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
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