Thread: proposal: alternative psql commands quit and exit
Some of us unfortunately have to work with multiple databases like Oracle or MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit" to exit sql client.
--
Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using "quit" and "exit" but for compatibility with psql, it also supports "\q" and "\quit".
Postgres psql already support "\q" and "\quit" but I think that could be cool if it supports "exit" and "quit", talking to friends I saw that I am the only that sometimes try to exit psql with "exit'.
The attached patch implements this way to exit psql.
Regards
Everaldo Canuto
Attachment
Everaldo Canuto wrote: > Some of us unfortunately have to work with multiple databases like Oracle or MySQL. > Their respective clients mysql and sqlplus uses "quit" or "exit" to exit sql client. > > Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using > "quit" and "exit" but for compatibility with psql, it also supports "\q" and "\quit". > > Postgres psql already support "\q" and "\quit" but I think that could be cool > if it supports "exit" and "quit", talking to friends I saw that I am the only > that sometimes try to exit psql with "exit'. > The attached patch implements this way to exit psql. I am -1 on that, because I think that it is not good to break the simple rule that everything that is a psql command starts with a backslash. It might reach out to newcomers, but it will confuse people who know psql. And frankly, anybody who has used sqlplus is used to suffering anyway. Yours, Laurenz Albe
Why not just use ctrl+D shortcut? This EOF signal works both in bash, mysql, psql, any CLI tool which I remember
On Fri, Dec 8, 2017 at 5:22 AM, Sergei Kornilov <sk@zsrv.org> wrote:
Why not just use ctrl+D shortcut? This EOF signal works both in bash, mysql, psql, any CLI tool which I remember
Because like I wrote, other sql clients also support "exit" and "quit".
On Fri, Dec 8, 2017 at 4:00 AM, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
I am -1 on that, because I think that it is not good to break the simple rule
that everything that is a psql command starts with a backslash.
We already have "help" command without slash and that is why I implement in the same way help is implemented.
Also, I don't really break the rules, usual way still works, I just added an alternative way.
It might reach out to newcomers, but it will confuse people who know psql.
For people already know psql nothing is changed, we will just have a hidden way to exit.
I just think that if it don't change or break anything for usual psql user but also help some new comers, then is good.
And remember, mysql client implement "\q" and "\quit" just to be more friendly to psql users. Lets us be friendly too ;-)
Regards
On Fri, Dec 8, 2017 at 7:06 PM, Everaldo Canuto <everaldo.canuto@gmail.com> wrote: > For people already know psql nothing is changed, we will just have a hidden > way to exit. > > I just think that if it don't change or break anything for usual psql user > but also help some new comers, then is good. > > And remember, mysql client implement "\q" and "\quit" just to be more > friendly to psql users. Lets us be friendly too ;-) I think that you are going to need better reasons than just being more friendly with other database clients by breaking a rule which is around for 20 years. For one, it seems to me that your patch is breaking multi-line SQL support with psql, as "quit" or "exit" are legit SQL object names. -- Michael
On Fri, Dec 8, 2017 at 8:10 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
I think that you are going to need better reasons than just being more
friendly with other database clients by breaking a rule which is
around for 20 years.
Well, that reason was enough for other sql clients to implement "\q" and "\quit" even if they don't use "\" commands.
Note that we are not breaking a rule, we already have "help" without slash and as I said, "slash way" still supported and still oficial way to exit.
For one, it seems to me that your patch is
breaking multi-line SQL support with psql, as "quit" or "exit" are
legit SQL object names.
No, it is not breaking. Did you test it? My patch takes care of multi-line commands. Look at second line of patch:
pset.cur_cmd_interactive && query_buf->len == 0
Line 4 also take care about other possible problems:
(line[4] == '\0' || line[4] == ';' || isspace((unsigned char) line[4])))
I know that this "feature" don't make any difference for most of you guys but also it will not hurt anyone and will help a little for newcomers and people that uses different sql clients. To be honest. I could understand that is not a good idea to accept patches like this if it is too big since it could make things hard to maintainers but honestly, this patch is very small and trivial.
Regards.
On Fri, Dec 8, 2017 at 2:10 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
I think that you are going to need better reasons than just being more
friendly with other database clients ...
This is not about other database clients. This is about users considering migration to Postgres.
People!
I'm definitely +1 for this, I've seen many people struggling because of this. Being more friendly to new users = more users in future.
At least "quit" and "exit" might be aliases for "help".
Everaldo Canuto wrote: > Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using > "quit" and "exit" but for compatibility with psql, it also supports "\q" > and "\quit". When looking at the most popular postgres questions on stackoverflow: https://stackoverflow.com/questions/tagged/postgresql?sort=votes the first one (most up-voted) happens to be: "How to exit from PostgreSQL command line utility: psql" now at 430k views and 1368 upvotes. Independently of the syntax-compatibility with other tools, it can be a miserable experience for people who almost never use psql to type "quit" or "exit" after they're done with whatever they wanted to do, and nothing happens except a tiny change in the prompt. Implementing it is easy, but it might be a hard sell for the project because it creates a precedent. The next question in that list is "PostgreSQL DESCRIBE TABLE", so why not implement "desc tablename;" as a synonym for "\d tablename"? The question after that is "Show tables in PostgreSQL", so why not implement "show tablename;"? Well, this one is impossible because SHOW is already a SQL command that does something else, so that's already the end of that road to compatibility. Personally I'm +1 on accepting the additional "exit" and "quit" as synonyms for \q, to comply with the "Do What I Mean" UX rule, rather than just compatibility with other tools. I guess this is why "help" is already a synonym of \h. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
I am +1 on doing this too, unless we can imagine it clashing with any SQL queries or breaking scripts (which I can't).
Helping people migrate to postgres w minimal frustration is important enough imho to be worth breaking this \ rule unless we can forsee real actual compatibility problems. We already have "help", so it's not like we have literally 0 commands that don't start with \.
Best,
Ryan
Hello,
On Fri, Dec 8, 2017 at 11:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote:
Implementing it is easy, but it might be a hard sell for the project
because it creates a precedent.
We already have "help" (without slash) so I don't think it is a precedent.
The next question in that list is "PostgreSQL DESCRIBE TABLE", so
why not implement "desc tablename;" as a synonym for
"\d tablename"?
I must be honest to you, I create this small patch to see how is contribute do Postgres and to check how is reception on Postgres community.
That said, DESC[RIBE] is on my list for next patches but it is not a synonym to \d.
DESC[RIBE] must be a SQL command, very useful when you are not running psql. But let us discuss this on another thread ;-)
The question after that is "Show tables in PostgreSQL", so
why not implement "show tablename;"? Well, this one is
impossible because SHOW is already a SQL command that does
something else, so that's already the end of that road to
compatibility.
Didn't know about SHOW command. Are TABLES a reserved word?
Regards.
On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto <everaldo.canuto@gmail.com> wrote: > Some of us unfortunately have to work with multiple databases like Oracle or > MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit" to > exit sql client. > > Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using > "quit" and "exit" but for compatibility with psql, it also supports "\q" and > "\quit". > > Postgres psql already support "\q" and "\quit" but I think that could be > cool if it supports "exit" and "quit", talking to friends I saw that I am > the only that sometimes try to exit psql with "exit'. +1 from me. When I first used Postgres I struggled with how to quit psql. I felt that making people look up how to quit the program is bad UI design. I admired Postgres as a database, but had the impression that it was harder to use than MySQL. Not being able to quit or describe a table in the way I was used to was frustrating. If anyone is unsure on this point, I'd recommend reading Joel Spolsky's articles on UI design. He clearly explains how a program model should match a user model. The fact that it's always been done this way is irrelevant to new users, who want a db that is intuitive.
Didn't know about SHOW command. Are TABLES a reserved word?
There isn't going to be that much appetite for this just so that people can use PostgreSQL without reading our documentation: or the output of typing "help" at the psql prompt that says "type \q to quit".
I don't know how one would go about reasonably writing extensions for psql but that, to me, would be the preferred approach. Then people could install whichever compatability module they'd like.
I'll agree that exiting the program is a special case that merits consideration - and it has been given that in the form of the concession to the word "help" in order to get the reader unfamiliar with our backslash prefix a non-backslash way to obtain that knowledge apart from reading our docs. Under that premise I would accept (lacking compelling arguments for why its a bad idea) this proposal for quit/exit but am against anything beyond that.
David J.
There isn't going to be that much appetite for this just so that people can use PostgreSQL without reading our documentation: or the output of typing "help" at the psql prompt that says "type \q to quit".
Agree with this. The whole reason people here are reluctant to add "quit" in the first place is that it could become a slippery slope where people now want every popular MySQL/Oracle command cloned, just so they can avoid reading docs and never understand the design/power/elegance of Postgres.
For example, while I think "quit" is a good idea, it'd be a shame if it caused people to never find out about \ commands.
> I'll agree that exiting the program is a special case that merits consideration
Yes, I think we can find the right balance here. We don't need to suddenly start implementing SHOW TABLES, as attractive as that is to people who know MySQL.
On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto
<everaldo.canuto@gmail.com> wrote:
+1 from me. When I first used Postgres I struggled with how to quit
psql. I felt that making people look up how to quit the program is bad
UI design. I admired Postgres as a database, but had the impression
that it was harder to use than MySQL.
Not being able to quit or
describe a table in the way I was used to was frustrating.
Whomever comes second is almost always going to have that problem.
who want a db that is intuitive.
Intuitive and "works like xyz" are not the same thing ...
If you want to argue that "prefixing commands with a backslash" is not intuitive then fine - though in a program where most of the stuff I write is meant to be sent to the server for interpretation knowing that if I place a backslash in front of it I will instead have the subsequent text interpreted locally, while not "intuitive", is obvious and consistent once I've learned the rule. That it also allows for mixing server and client targeted text further reinforces that boon. Having both backslash and non-backslash ways to done something just puts more information into my head that I need to sift through when learning the program.
Pretty much every interactive shell program in existence needs an exit/quit command so flexing here to match the most common, and used in every session, command seems worthwhile to me. Creating non-backslash variants of every psql command that exists does not (and many wouldn't make sense or work anyways). Because of that I'd be inclined to be internally consistent and mandate backslash for everything and understand that it does add a small grade to the learning curve for those coming from other database clients. Refraining from making our client more complex to learn for the first-time db user seems more important than making it so experienced db users don't have to learn certain parts at all.
David J.
There isn't going to be that much appetite for this just so that people can use PostgreSQL without reading our documentation: or the output of typing "help" at the psql prompt that says "type \q to quit".For example, while I think "quit" is a good idea, it'd be a shame if it caused people to never find out about \ commands.
I suppose the only bad thing about introducing "exit", which itself seems like the more common choice for program stopping command, is that someone might end up inferring that "\e" should work to exit the program instead of opening an editor...
David J.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I'll agree that exiting the program is a special case that merits
> consideration - and it has been given that in the form of the concession to
> the word "help" in order to get the reader unfamiliar with our backslash
> prefix a non-backslash way to obtain that knowledge apart from reading our
> docs. Under that premise I would accept (lacking compelling arguments for
> why its a bad idea) this proposal for quit/exit but am against anything
> beyond that.
Meh. I never thought that the "help" business was particularly well
thought out, and this proposal isn't better. The reason is that to
avoid breaking multi-line SQL command entry, we can only accept such
a command when the input buffer is empty. A psql novice is unlikely
to be familiar with that concept, let alone know that \r or ^C is the
way to get there. There's a weak argument that "help" is of some
value because it's likely to be the first thing a novice types, but
that doesn't apply for quit/exit. The typical interaction I'd foresee
is more like
postgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exit
with nothing accomplished except to increase the user's frustration
each time. Eventually she'll hit on ^D and get out of it, but none
of these allegedly novice-friendly "features" helped at all.
regards, tom lane
On 8 December 2017 at 15:34, Oliver Ford <ojford@gmail.com> wrote:
On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto
<everaldo.canuto@gmail.com> wrote:
> Some of us unfortunately have to work with multiple databases like Oracle or
> MySQL. Their respective clients mysql and sqlplus uses "quit" or "exit" to
> exit sql client.
>
> Oracle's sqlplus uses "quit" or "exit" and MySQL client can be exited using
> "quit" and "exit" but for compatibility with psql, it also supports "\q" and
> "\quit".
>
> Postgres psql already support "\q" and "\quit" but I think that could be
> cool if it supports "exit" and "quit", talking to friends I saw that I am
> the only that sometimes try to exit psql with "exit'.
+1 from me. When I first used Postgres I struggled with how to quit
psql. I felt that making people look up how to quit the program is bad
UI design. I admired Postgres as a database, but had the impression
that it was harder to use than MySQL. Not being able to quit or
describe a table in the way I was used to was frustrating.
If anyone is unsure on this point, I'd recommend reading Joel
Spolsky's articles on UI design. He clearly explains how a program
model should match a user model. The fact that it's always been done
this way is irrelevant to new users, who want a db that is intuitive.
Well, if I have a new program I usually read some documentation. It really helps people to exit vim as well :)
Thinking this way for me psql's way is the intuitive one, because I know it.
Should I kindly ask Oracle to change their programs because I rather want to use their software than reading their documentation?
Should I kindly ask Oracle to change their programs because I rather want to use their software than reading their documentation?
regards
Szymon Lipiński
"David G. Johnston" <david.g.johnston@gmail.com> writes:
A psql novice is unlikely
to be familiar with that concept, let alone know that \r or ^C is the
way to get there. There's a weak argument that "help" is of some
value because it's likely to be the first thing a novice types, but
that doesn't apply for quit/exit. The typical interaction I'd foresee
is more like
postgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exit
with nothing accomplished except to increase the user's frustration
each time. Eventually she'll hit on ^D and get out of it, but none
of these allegedly novice-friendly "features" helped at all.
help -> exit -> (they may think of "quit" ...)
My major CLI experience is bash and for this I use "exit", and in Windows you go to "File -> Exit". Quit makes sense but exit is more common. I'm inclined to buy into this proposal for that reason alone. The usage problem you demonstrate is only somewhat valid since the level of frustration depends on whether they are just tying commands or know from the docs that "quit" is supposed to work. And even backslash commands won't work if you leaving the session in the middle of text literal. So, I'll agree but all of the mitigation above means I don't think this proposal makes the situation much (if at all) worse if they aren't reading the docs and can be lessened if they are.
David J.
I wonder if exit; to terminate loop be confused with exit psql in case of bad syntax. then instead of reporting error in plpgsql it would just silently exit?..
2017-12-08 15:19 GMT+00:00 Tom Lane <tgl@sss.pgh.pa.us>:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I'll agree that exiting the program is a special case that merits
> consideration - and it has been given that in the form of the concession to
> the word "help" in order to get the reader unfamiliar with our backslash
> prefix a non-backslash way to obtain that knowledge apart from reading our
> docs. Under that premise I would accept (lacking compelling arguments for
> why its a bad idea) this proposal for quit/exit but am against anything
> beyond that.
Meh. I never thought that the "help" business was particularly well
thought out, and this proposal isn't better. The reason is that to
avoid breaking multi-line SQL command entry, we can only accept such
a command when the input buffer is empty. A psql novice is unlikely
to be familiar with that concept, let alone know that \r or ^C is the
way to get there. There's a weak argument that "help" is of some
value because it's likely to be the first thing a novice types, but
that doesn't apply for quit/exit. The typical interaction I'd foresee
is more like
postgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exit
with nothing accomplished except to increase the user's frustration
each time. Eventually she'll hit on ^D and get out of it, but none
of these allegedly novice-friendly "features" helped at all.
regards, tom lane
On Fri, Dec 8, 2017 at 2:26 PM, Vladimir Svedov <vodevsh@gmail.com> wrote:
I wonder if exit; to terminate loop be confused with exit psql in case of bad syntax. then instead of reporting error in plpgsql it would just silently exit?..
if (pset.cur_cmd_interactive && query_buf->len == 0 &&
On Fri, Dec 8, 2017 at 3:10 PM, David G. Johnston <david.g.johnston@gmail.com> wrote: > On Fri, Dec 8, 2017 at 7:34 AM, Oliver Ford <ojford@gmail.com> wrote: >> >> On Thu, Dec 7, 2017 at 11:47 PM, Everaldo Canuto >> <everaldo.canuto@gmail.com> wrote: >> >> +1 from me. When I first used Postgres I struggled with how to quit >> psql. I felt that making people look up how to quit the program is bad >> UI design. I admired Postgres as a database, but had the impression >> that it was harder to use than MySQL. > > >> >> Not being able to quit or >> describe a table in the way I was used to was frustrating. > > > Whomever comes second is almost always going to have that problem. And for most people, Postgres is their second or third database. >> who want a db that is intuitive. > > > Intuitive and "works like xyz" are not the same thing ... Most people will have worked with Bash, Powershell, MySQL, etc and for them intuitive means typing exit or quit. It would be strange to them that psql behaves differently than what they're used to. My guess would be that this quitting difficulty put more people off Postgres than anything to do with the backend. First impressions count when retaining users.
On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote: > When looking at the most popular postgres questions on stackoverflow: > > https://stackoverflow.com/questions/tagged/postgresql?sort=votes > > the first one (most up-voted) happens to be: > > "How to exit from PostgreSQL command line utility: psql" > > now at 430k views and 1368 upvotes. Wow, that's pretty crazy. I was going to vote against this proposal, but I think I might change my mind. How can we say that this isn't a problem for users given that data? It's evidently not only *a* problem, but arguably the biggest one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote: >> When looking at the most popular postgres questions on stackoverflow: >> https://stackoverflow.com/questions/tagged/postgresql?sort=votes >> the first one (most up-voted) happens to be: >> "How to exit from PostgreSQL command line utility: psql" >> now at 430k views and 1368 upvotes. > Wow, that's pretty crazy. I was going to vote against this proposal, > but I think I might change my mind. How can we say that this isn't a > problem for users given that data? It's evidently not only *a* > problem, but arguably the biggest one. I actually agree that there's a problem there. What I find pretty dubious is the claim that this patch will fix it. If we could see our way to recognizing help/quit/exit on a line by themselves even when there's data in the query buffer, the argument that we've improved matters for novices would be *far* stronger. However, given that this is legal, fully-spec-compliant SQL: select a, b exit from mytable; I'm not sure how we could get away with that. Would it pass muster to do that only when isatty(stdin)? Other ideas? regards, tom lane
On 08 Des. 2017, at 20:56 , Robert Haas <robertmhaas@gmail.com> wrote:
Sounds like the VI exit issue?
On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote:When looking at the most popular postgres questions on stackoverflow:
https://stackoverflow.com/questions/tagged/postgresql?sort=votes
the first one (most up-voted) happens to be:
"How to exit from PostgreSQL command line utility: psql"
now at 430k views and 1368 upvotes.
Wow, that's pretty crazy. I was going to vote against this proposal,
but I think I might change my mind. How can we say that this isn't a
problem for users given that data? It's evidently not only *a*
problem, but arguably the biggest one.
Having “made that ‘mistake’” once, by lots of users, does that imply it is a constant problem for those users?
Will, having the psql exit the same as msql/etc., make people rather use PostgreSQL than MySQL?
Is it really such a huge barrier to entry for users/sysadmins/developers?
Most users/developers I coming from the MSSQL type world is looking for a GUI to manage their DB, and in that regard MySQL has argue-ably a “better” tool with the name Workbench compared to PGAdmin.
On Fri, Dec 8, 2017 at 10:28 AM, Szymon Lipiński <mabewlun@gmail.com> wrote: > Well, if I have a new program I usually read some documentation. It really > helps people to exit vim as well :) Look, I love vim and use it constantly, but no reasonable person is going to hold it up as a good example of user-friendly software. According to Wikipedia, it was written in 1976 by Bill Joy, and computers have come a long way in the last 40 years. They are, broadly, easier to use now. For example, current versions of vim let you move around using new-fangled arrow keys, as if computers were supposed to cater to the lowest common denominator! Real men (like me) use hjkl to get around the screen, and look upon those who resort to the arrow keys as Johnny-come-latelys. Nevertheless, I can hardly fault vim/vi's concession to modernity in this regard. > Thinking this way for me psql's way is the intuitive one, because I know it. > Should I kindly ask Oracle to change their programs because I rather want to > use their software than reading their documentation? If you can convince Oracle to add support for \q to sqlplus, I say go for it. Actually, what I'd like even better is if you could convince them to add curses support, but I guess they would have done that 30 years ago if they were inclined to do it. Really good software -- which sqlplus is not -- doesn't make it necessary to read the documentation. It helps you figure out how to use it as you go. When I fire up a new app on my iPhone, it generally gives me a clue how to use it. Sure, there's probably an app in the Apple Store someplace that is absolutely unusable without reading the documentation, but that's a bug, not a feature. It's expected that you'll have to read the documentation to figure out how to use the advanced features of any complicated program, but that doesn't mean we should make simple things complicated just to scare off users that aren't sufficiently committed to the Cause. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Dec 8, 2017 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Wow, that's pretty crazy. I was going to vote against this proposal, >> but I think I might change my mind. How can we say that this isn't a >> problem for users given that data? It's evidently not only *a* >> problem, but arguably the biggest one. > > I actually agree that there's a problem there. What I find pretty dubious > is the claim that this patch will fix it. There's no silver bullet for usability issues. > If we could see our way to recognizing help/quit/exit on a line by > themselves even when there's data in the query buffer, the argument > that we've improved matters for novices would be *far* stronger. > However, given that this is legal, fully-spec-compliant SQL: > > select a, b > exit > from mytable; > > I'm not sure how we could get away with that. Would it pass muster to do > that only when isatty(stdin)? Other ideas? What if we made it so that "exit" or "quit" bails out entirely when not in a continuation line, and when entered on a continuation line, provided isatty(stdin), prints some kind of message telling you that you're in a continuation line? For example, if you type "help" on a continuation line by itself it says something like "use \? for help or press control-C to abandon the command currently in the input buffer" and if you type "exit" or "quit" on a a continuation line by itself it says something like "use \q to quit or press control-C to abandon the command currently in the input buffer". Either thing will happen in addition to, not instead of, adding the text to the current input buffer. That way, your valid SQL command will still work, but you'll get a hint that you may want to choose a less-confusing place to put your line breaks. And if, as is more likely, you are a confused new user, you will get a clue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 8, 2017 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not sure how we could get away with that. Would it pass muster to do
>> that only when isatty(stdin)? Other ideas?
> What if we made it so that "exit" or "quit" bails out entirely when
> not in a continuation line, and when entered on a continuation line,
> provided isatty(stdin), prints some kind of message telling you that
> you're in a continuation line?
Yeah, that might work. As you say, if it only prints some chatter
(to stderr, I guess) without changing the semantics of the input,
it gets easier to defend.
regards, tom lane
On Sat, Dec 9, 2017 at 3:56 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote: >> When looking at the most popular postgres questions on stackoverflow: >> >> https://stackoverflow.com/questions/tagged/postgresql?sort=votes >> >> the first one (most up-voted) happens to be: >> >> "How to exit from PostgreSQL command line utility: psql" >> >> now at 430k views and 1368 upvotes. > > Wow, that's pretty crazy. I was going to vote against this proposal, > but I think I might change my mind. How can we say that this isn't a > problem for users given that data? It's evidently not only *a* > problem, but arguably the biggest one. That's an impressive number, indeed. And an argument about potentially doing something. -- Michael
Most popular questions on every topic are the simplest ones. Imagine a parallel universe where this patch is contained in the codebase - I argue this question about exiting the repl still is the top one, albeit with less votes.
On Sat, Dec 9, 2017, 11:03 Michael Paquier <michael.paquier@gmail.com> wrote:
On Sat, Dec 9, 2017 at 3:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote:
>> When looking at the most popular postgres questions on stackoverflow:
>>
>> https://stackoverflow.com/questions/tagged/postgresql?sort=votes
>>
>> the first one (most up-voted) happens to be:
>>
>> "How to exit from PostgreSQL command line utility: psql"
>>
>> now at 430k views and 1368 upvotes.
>
> Wow, that's pretty crazy. I was going to vote against this proposal,
> but I think I might change my mind. How can we say that this isn't a
> problem for users given that data? It's evidently not only *a*
> problem, but arguably the biggest one.
That's an impressive number, indeed. And an argument about potentially
doing something.
--
Michael
Tom Lane wrote:
> The typical interaction I'd foresee is more like
>
> postgres=> select 2+2 (user forgets semicolon)
> postgres-> help
> postgres-> quit
> postgres-> exit
A part of this is due to the default PROMPT2 being too similar to PROMPT1.
The significance of '=' turning to '-' is easily lost on newbies.
By comparison, the mysql client seems a bit more intuitive
for this, with this presentation:
mysql> select 2+2
-> help
-> quit
-> exit
The "mysql" part is replaced by spaces on secondary prompts, so
visually it's more obvious that it's a different state.
The space-padding is necessary to keep the user input left-aligned.
Maybe PROMPT2 could be improved in that direction in psql.
For instance, I wonder if it'd be doable to have PROMPT2 with the line
number and proper alignment, so the above session could end up displayed
like this:
postgres=> select 2+2
2-> help
3-> quit
4-> exit
That way, the more lines are typed, the more it becomes obvious that
you're in a multi-line statement. Plus numbering lines might
be useful in general, anyway.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
On Sat, Dec 9, 2017 at 11:36 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote:
postgres=> select 2+2
2-> help
3-> quit
4-> exit
I like it! Maybe another proposal to change PROMPT2?
On Sat, Dec 9, 2017 at 1:27 AM, Rok Kralj <rok.kralj@gmail.com> wrote:
Most popular questions on every topic are the simplest ones. Imagine a parallel universe where this patch is contained in the codebase - I argue this question about exiting the repl still is the top one, albeit with less votes.
On Sat, Dec 9, 2017, 11:03 Michael Paquier <michael.paquier@gmail.com> wrote:On Sat, Dec 9, 2017 at 3:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" <daniel@manitou-mail.org> wrote:
>> When looking at the most popular postgres questions on stackoverflow:
>>
>> https://stackoverflow.com/questions/tagged/postgresql? sort=votes
>>
>> the first one (most up-voted) happens to be:
>>
>> "How to exit from PostgreSQL command line utility: psql"
>>
>> now at 430k views and 1368 upvotes.
>
> Wow, that's pretty crazy. I was going to vote against this proposal,
> but I think I might change my mind. How can we say that this isn't a
> problem for users given that data? It's evidently not only *a*
> problem, but arguably the biggest one.
That's an impressive number, indeed. And an argument about potentially
doing something.
Far less concrete, I can tell you this: Over the last 10 years, I've averaged teaching ~ 2 PG classes per quarter to students from every background: Database (you name it), OS admin, developer, consultant, etc...
I have the students use pgbench to generate some data, run some queries and pg_dump it.
EVERY single class has at least one:
postgres=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------------+-------+----------
public | pgbench_accounts | table | postgres
public | pgbench_branches | table | postgres
public | pgbench_history | table | postgres
public | pgbench_tellers | table | postgres
(4 rows)
postgres=# exit
postgres-# pg_dump
postgres-# pg_dump
postgres-# pg_dump
postgres-# pg_dump --help
postgres-# ls
postgres-# cd
postgres-# exit
postgres-# quit
postgres-#
It's not just usability, it's a point of serious frustration for seasoned database people.
+1
--
Michael
Everaldo Canuto wrote: > > > > postgres=> select 2+2 > > 2-> help > > 3-> quit > > 4-> exit > > > I like it! Maybe another proposal to change PROMPT2? Thanks. Yes, I think it should be a different proposal. On closer inspection, mysql doesn't make a real effort to align prompts, the secondary prompt happens to coincide with the default primary prompt, but when it's non-default, the alignment is lost. Their secondary prompt does not seem to be configurable. By contrast PROMPT2 is fully configurable in psql. The issue of alignment is non-trivial if we wish to retain the nice-to-have property that if you copy-paste psql session in an editor, the prompting can generally be filtered out with a simple column-cut. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
On Fri, Dec 08, 2017 at 02:12:06PM -0500, Robert Haas wrote: > On Fri, Dec 8, 2017 at 10:28 AM, Szymon Lipiński <mabewlun@gmail.com> wrote: > > Well, if I have a new program I usually read some documentation. It really > > helps people to exit vim as well :) > > Look, I love vim and use it constantly, but no reasonable person is > going to hold it up as a good example of user-friendly software. > According to Wikipedia, it was written in 1976 by Bill Joy, and > computers have come a long way in the last 40 years. They are, > broadly, easier to use now. For example, current versions of vim let > you move around using new-fangled arrow keys, as if computers were > supposed to cater to the lowest common denominator! Real men (like > me) use hjkl to get around the screen, and look upon those who resort > to the arrow keys as Johnny-come-latelys. Nevertheless, I can hardly > fault vim/vi's concession to modernity in this regard. > > > Thinking this way for me psql's way is the intuitive one, because I know it. > > Should I kindly ask Oracle to change their programs because I rather want to > > use their software than reading their documentation? > > If you can convince Oracle to add support for \q to sqlplus, I say go > for it. Actually, what I'd like even better is if you could convince > them to add curses support, but I guess they would have done that 30 > years ago if they were inclined to do it. > > Really good software -- which sqlplus is not -- doesn't make it > necessary to read the documentation. It helps you figure out how to > use it as you go. When I fire up a new app on my iPhone, it generally > gives me a clue how to use it. Sure, there's probably an app in the > Apple Store someplace that is absolutely unusable without reading the > documentation, but that's a bug, not a feature. It's expected that > you'll have to read the documentation to figure out how to use the > advanced features of any complicated program, but that doesn't mean we > should make simple things complicated just to scare off users that > aren't sufficiently committed to the Cause. +1 Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 12/8/17 14:08, hvjunk wrote: > Sounds like the VI exit issue? > https://stackoverflow.com/questions/11828270/how-to-exit-the-vim-editor > > Having “made that ‘mistake’” once, by lots of users, does that imply it > is a constant problem for those users? Yeah, I'm not sure I buy the way we are reading these statistics here. Presumably, 100% of psql users have an interest in how to quit it, and maybe 0.1% of those have a question about how to do it and maybe 10% of those go to SO and 10% of those upvote the question because SO encourages it. On the other hand, perhaps 0.0005% of psql users have an interest in making psql print HTML tables, but 50% of those are struggling with it. Which problem would really need addressing? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 12/8/17 10:19, Tom Lane wrote:
> Meh. I never thought that the "help" business was particularly well
> thought out, and this proposal isn't better.
The irony is that before the "help" thing was put in, the psql startup
message said
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
The perhaps the fix is to revert the "help" thing?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
This one I’ll support to have those messages brought back for psql (especially when it’s connected to a pty), as then theSO question would fade away into obscurity (At least for those users that actually read :D ) > On 09 Des. 2017, at 11:45 nm., Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > The irony is that before the "help" thing was put in, the psql startup > message said > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help with psql commands > \g or terminate with semicolon to execute query > \q to quit > > The perhaps the fix is to revert the "help" thing? > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 12/8/17 10:19, Tom Lane wrote:
>> Meh. I never thought that the "help" business was particularly well
>> thought out, and this proposal isn't better.
> The perhaps the fix is to revert the "help" thing?
No, my problem with it is that there are lots of contexts where typing
"help" won't produce anything. Robert's proposal downthread would
go a long way towards fixing that.
regards, tom lane
On Sat, Dec 9, 2017 at 12:59 PM, David Fetter <david@fetter.org> wrote:
>
> On Fri, Dec 08, 2017 at 02:12:06PM -0500, Robert Haas wrote:
> > On Fri, Dec 8, 2017 at 10:28 AM, Szymon Lipiński <mabewlun@gmail.com> wrote:
> > > Well, if I have a new program I usually read some documentation. It really
> > > helps people to exit vim as well :)
> >
> > Look, I love vim and use it constantly, but no reasonable person is
> > going to hold it up as a good example of user-friendly software.
> > According to Wikipedia, it was written in 1976 by Bill Joy, and
> > computers have come a long way in the last 40 years. They are,
> > broadly, easier to use now. For example, current versions of vim let
> > you move around using new-fangled arrow keys, as if computers were
> > supposed to cater to the lowest common denominator! Real men (like
> > me) use hjkl to get around the screen, and look upon those who resort
> > to the arrow keys as Johnny-come-latelys. Nevertheless, I can hardly
> > fault vim/vi's concession to modernity in this regard.
> >
> > > Thinking this way for me psql's way is the intuitive one, because I know it.
> > > Should I kindly ask Oracle to change their programs because I rather want to
> > > use their software than reading their documentation?
> >
> > If you can convince Oracle to add support for \q to sqlplus, I say go
> > for it. Actually, what I'd like even better is if you could convince
> > them to add curses support, but I guess they would have done that 30
> > years ago if they were inclined to do it.
> >
> > Really good software -- which sqlplus is not -- doesn't make it
> > necessary to read the documentation. It helps you figure out how to
> > use it as you go. When I fire up a new app on my iPhone, it generally
> > gives me a clue how to use it. Sure, there's probably an app in the
> > Apple Store someplace that is absolutely unusable without reading the
> > documentation, but that's a bug, not a feature. It's expected that
> > you'll have to read the documentation to figure out how to use the
> > advanced features of any complicated program, but that doesn't mean we
> > should make simple things complicated just to scare off users that
> > aren't sufficiently committed to the Cause.
>
> +1
>
And what about create some way to create aliases for meta-commands in psql? Something like:
\alias quit \q
\alias exit \q
We also can create a special config variable to enable/disable use of aliases:
We also can create a special config variable to enable/disable use of aliases:
\set USE_ALIAS on
Regards,
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello
Hello.
On Mon, Dec 11, 2017 at 11:14 AM, Fabrízio de Royes Mello <fabriziomello@gmail.com> wrote:
And what about create some way to create aliases for meta-commands in psql? Something like:\alias quit \q\alias exit \q
We also can create a special config variable to enable/disable use of aliases:\set USE_ALIAS on
I don't think it will fix the problem, if you don't know how to use "\q", "\alias exit \q" and "exit" will be even harder.
Remember, it is basically to help newcomers.
On Mon, Dec 11, 2017 at 11:14:29AM -0200, Fabrízio de Royes Mello wrote: > And what about create some way to create aliases for meta-commands in psql? At first blush, this sounds interesting, but on further reflection, it seems more like a MASSIVE foot gun on the useability/getting help side, and likely has non-trivial negative implications for access control and security. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 12/9/17 19:28, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> On 12/8/17 10:19, Tom Lane wrote: >>> Meh. I never thought that the "help" business was particularly well >>> thought out, and this proposal isn't better. > >> The perhaps the fix is to revert the "help" thing? > > No, my problem with it is that there are lots of contexts where typing > "help" won't produce anything. Robert's proposal downthread would > go a long way towards fixing that. No opinion on that, but if the problem is that people don't know how to quit psql, then we should just put that information back into the welcome message and be done with it. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 12/9/17 19:28, Tom Lane wrote:
>> No, my problem with it is that there are lots of contexts where typing
>> "help" won't produce anything. Robert's proposal downthread would
>> go a long way towards fixing that.
> No opinion on that, but if the problem is that people don't know how to
> quit psql, then we should just put that information back into the
> welcome message and be done with it.
I don't think people read the welcome message, or at least they
immediately forget it.
regards, tom lane
On 12/11/2017 04:16 PM, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> No opinion on that, but if the problem is that people don't know how to >> quit psql, then we should just put that information back into the >> welcome message and be done with it. > > I don't think people read the welcome message, or at least they > immediately forget it. I'm still a wholehearted supporter of Robert's idea in https://www.postgresql.org/message-id/CA%2BTgmoZswp00PtcgPfQ9zbbh7HUTgsLLJ9Z1x9E2s8Y7ep048g%40mail.gmail.com to simply produce helpful messages to stderr when isatty(stdin) and 'exit' or 'quit' arrives on a line by itself. Simple, clear, you end up learning how psql works, and getting help doing it, at the moment you want it. No change to semantics. Brilliant. I'm not just saying that because its exactly the suggestion I was preparing to compose when I scrolled to Robert's message and saw I'd been scooped. (Or maybe I am.) I don't even think it's necessarily worthwhile to treat them any differently when *not* on a continuation line. Why not just always have a bare 'exit' or 'quit', when isatty(stdin), give you a little reminder about \?, \q, ^C/\r and leave the next step up to you? Maybe the part of the reminder about ^C / \r to clear the input buffer could be reserved for when the buffer isn't empty. On second thought, no, it will be appropriate every time, because now the buffer has at least your exit or quit in it. -Chap
On 12 December 2017 at 05:38, Chapman Flack <chap@anastigmatix.net> wrote:
-- On 12/11/2017 04:16 PM, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> No opinion on that, but if the problem is that people don't know how to
>> quit psql, then we should just put that information back into the
>> welcome message and be done with it.
>
> I don't think people read the welcome message, or at least they
> immediately forget it.
I'm still a wholehearted supporter of Robert's idea in
https://www.postgresql.org/message-id/CA% 2BTgmoZswp00PtcgPfQ9zbbh7HUTgs LLJ9Z1x9E2s8Y7ep048g%40mail. gmail.com
to simply produce helpful messages to stderr when isatty(stdin) and
'exit' or 'quit' arrives on a line by itself.
+1 from me. In part because scripts you write on pg11 won't break on older versions with weird errors due to lack of 'exit' / 'quit' .
As others noted, 'help' is a precedent here.
I don't even think it's necessarily worthwhile to treat them any
differently when *not* on a continuation line. Why not just always
have a bare 'exit' or 'quit', when isatty(stdin), give you a little
reminder about \?, \q, ^C/\r and leave the next step up to you?
This makes me a little nervous... but the counter-argument is that I see a lot of stack overflow questions with variants on "nothing is working in psql". Because they didn't use a semicolon. So they're stuck in a continuation, mashing help and quit and exit and wondering wtf is going on. The same happens with people who get stuck in quote continuations or open-parens continuations, where semicolon doesn't help them either.
Experienced users on unixes will try control-D, but unless you've used unix a while that's not going to occur to you.
I doubt I've ever written just "exit" or "quit" without indentation. I think if it requires them to be a bareword with no indentation, strictly ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice.
On 12 December 2017 at 05:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 12/9/17 19:28, Tom Lane wrote:
>> No, my problem with it is that there are lots of contexts where typing
>> "help" won't produce anything. Robert's proposal downthread would
>> go a long way towards fixing that.
> No opinion on that, but if the problem is that people don't know how to
> quit psql, then we should just put that information back into the
> welcome message and be done with it.
I don't think people read the welcome message, or at least they
immediately forget it.
What welcome message?
$ psqlpsql (9.6.4, server 9.5.8)
Type "help" for help.
craig=>
Oh, huh. There's something written below the version.
OK, you might argue that if I wasn't a constant psql user I wouldn't have learned to be blind to that yet. But I think many users are probably almost as blind to welcome messages are they are to banner ads. And lets face it, the users we're trying to reach aren't necessarily the best readers/problem solvers already.
Craig Ringer <craig@2ndquadrant.com> writes:
> I doubt I've ever written just "exit" or "quit" without indentation. I
> think if it requires them to be a bareword with no indentation, strictly
> ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice.
FWIW, I think that the special behavior (whatever it winds up being
exactly) ought to trigger on an input line matching
[whitespace]*help[whitespace]*(;[whitespace]*)?
and similarly for exit/quit. I think that novices might have internalized
enough SQL syntax to think that they need to terminate the command with a
semicolon --- in fact, we regularly see examples in which seasoned users
think they need to terminate backslash commands with a semicolon, so
that's hardly far-fetched. And we might as well allow as much whitespace
as we can, because nobody but Guido Rossum thinks that having whitespace
be semantically significant is a good idea.
regards, tom lane
On 12 December 2017 at 13:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Craig Ringer <craig@2ndquadrant.com> writes:
> I doubt I've ever written just "exit" or "quit" without indentation. I
> think if it requires them to be a bareword with no indentation, strictly
> ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice.
FWIW, I think that the special behavior (whatever it winds up being
exactly) ought to trigger on an input line matching
[whitespace]*help[whitespace]*(;[whitespace]*)?
and similarly for exit/quit. I think that novices might have internalized
enough SQL syntax to think that they need to terminate the command with a
semicolon --- in fact, we regularly see examples in which seasoned users
think they need to terminate backslash commands with a semicolon, so
that's hardly far-fetched. And we might as well allow as much whitespace
as we can, because nobody but Guido Rossum thinks that having whitespace
be semantically significant is a good idea.
Yeah, I think that's fine - and sensible - if we do what Robert proposed and pass it through to psql's buffer as well as printing some helptext.
It's probably not even that bad if we didn't pass it through, really, as those lines have little good reason to exist on their own, but I'd rather not push our luck.
On 12. 12. 2017 06:58, Tom Lane wrote: > Craig Ringer <craig@2ndquadrant.com> writes: >> I doubt I've ever written just "exit" or "quit" without indentation. I >> think if it requires them to be a bareword with no indentation, strictly >> ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice. > FWIW, I think that the special behavior (whatever it winds up being > exactly) ought to trigger on an input line matching > > [whitespace]*help[whitespace]*(;[whitespace]*)? > > and similarly for exit/quit. I think that novices might have internalized > enough SQL syntax to think that they need to terminate the command with a > semicolon --- in fact, we regularly see examples in which seasoned users > think they need to terminate backslash commands with a semicolon, so > that's hardly far-fetched. And we might as well allow as much whitespace > as we can, because nobody but Guido Rossum thinks that having whitespace > be semantically significant is a good idea. > > regards, tom lane > If tabs are considered whitespace, psql can sometimes treat it as semantically significant, since "create materialized<tab>test11 as select 1;" will be autocompleted to correct syntax if you paste the line into interactive psql session. I have seen psql error out with invalid syntax when a similar query was pasted and psql autocompleted it. kind regards, Gasper
I wouldn't exactly say -1 but it's a "meh" from me. On 8 December 2017 at 13:57, Daniel Vérité" <daniel@manitou-mail.org> wrote: > "How to exit from PostgreSQL command line utility: psql" > > now at 430k views and 1368 upvotes. There is also stackexchange question with 51000 views that asks how to start the postgresql client. Should we rename psql to mysql to help new users too? Ctrl-D works almost everywhere. It takes 2 seconds to find the answer and there are going to be many other things you have to find out if you're coming at PostgreSQL from a different DB. As others have pointed out, there are _far_ more frustrating things (like the lack of SHOW CREATE [TABLE|etc]... support in the backend) for anyone coming from mysql that I would suggest should be addressed if you were serious about making life easier for those moving DBs. Geoff
Someone mentioned about needing to read the documentation of vim to learn how to exit the program. I personally think exactly the same applies here, and am a bit surprised at the depth of discussion over this.
When I first was new to cli programs, the only "standard" way to exit a program I found across the board was CTRL+D. I have never even thought that psql, even though different, was odd in its choice of how to exit the program. And their choices for why \q is used in a SQL cli program have very good reasons as has been discussed.
So what if that stack overflow is the most hit on psql questions? How many of you have learned what you need within 5 seconds on google? I don't think this is a significant stumbling block for users adopting postgres. psql is amazing and for anyone who likes cli programs, they will be fine.
FWIW I am +1 in favor of not overcomplicating the special psql commands and keep to the "\" standard.
On Tue, Dec 12, 2017 at 8:35 AM, Gasper Zejn <zejn@owca.info> wrote:
If tabs are considered whitespace, psql can sometimes treat it asOn 12. 12. 2017 06:58, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> I doubt I've ever written just "exit" or "quit" without indentation. I
>> think if it requires them to be a bareword with no indentation, strictly
>> ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice.
> FWIW, I think that the special behavior (whatever it winds up being
> exactly) ought to trigger on an input line matching
>
> [whitespace]*help[whitespace]*(;[whitespace]*)?
>
> and similarly for exit/quit. I think that novices might have internalized
> enough SQL syntax to think that they need to terminate the command with a
> semicolon --- in fact, we regularly see examples in which seasoned users
> think they need to terminate backslash commands with a semicolon, so
> that's hardly far-fetched. And we might as well allow as much whitespace
> as we can, because nobody but Guido Rossum thinks that having whitespace
> be semantically significant is a good idea.
>
> regards, tom lane
>
semantically significant, since
"create materialized<tab>test11 as select 1;" will be autocompleted to
correct syntax if you paste the line into interactive psql session.
I have seen psql error out with invalid syntax when a similar query was
pasted and psql autocompleted it.
kind regards, Gasper
I don't think this is a significant stumbling block for users adopting postgres.
The OP complained, and I tend to agree, that 90% of the world uses the command "exit" to end a program and that it would be nice if we did as well. This is not just a new user consideration - and I'd say that making it so help/quit/exit/\q on a line of their own is helpfully reported to the user as having been ineffective if in the middle of a string or statement-continuation, would benefit more than just new users as well.
David J.
It takes a few hours to learn PostgreSQL and 1 second to remember, how to quit from psql.
Surprised to see the depth of discussion on this.
He knows about psql because he searched it somewhere. Just a psql --help (anybody uses help), should help me know much more about psql.
I think its good to talk about or help with more features that helps a production database.
It takes sometime for a person to explore or know about PostgreSQL and install it.
Likewise, it takes him some more time to understand that there exists a "psql" to connect to it. I think many people doesn't find it difficult to quit using \q.
On Tue, Dec 12, 2017 at 11:19 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
I don't think this is a significant stumbling block for users adopting postgres.The OP complained, and I tend to agree, that 90% of the world uses the command "exit" to end a program and that it would be nice if we did as well. This is not just a new user consideration - and I'd say that making it so help/quit/exit/\q on a line of their own is helpfully reported to the user as having been ineffective if in the middle of a string or statement-continuation, would benefit more than just new users as well.David J.
--
9000799060
On 12 December 2017 at 13:04, Jeremy Finzel <finzelj@gmail.com> wrote: > FWIW I am +1 in favor of not overcomplicating the special psql commands and > keep to the "\" standard. I find the general rule of \ starts a client command and anything else starts a server command to be very good to begin with. The 'help' is an ugly exception to the rule and I wouldn't like to see it expanding. If it were up to me, I'd rename 'help' to '\help' and add '\q' to the initial welcome message. Of course, that wouldn't be accepted and it wouldn't solve the SO statistics or the OP's complaint. It's been already established that we're now trying to cater to a special kind of user - not the one who doesn't want/have time to read the docs - but the one who didn't even read the start message or who read it and forgot what it was after a screen full of content has passed, then went to SO instead of the docs. (I'm not criticizing - just trying to paint a clear picture of the goal here.) And since I view the lonely exit|quit in an uglier solution still, how about this idea: Nano keeps a cheatsheet of commands on the bottom; and it's regarded as a fairly good editor for newcomers. Some shells have a right-hand side status bar. And even vim these days shows several lines of explanation of :q if you open it alone. If psql had a right-hand side status bar that defaulted to a short cheatsheet-like message like the initial "type 'help' for help and '\q' to quit" (perhaps empty if started with quiet), then it would follow new users around on every new command, so they would always know how to quit or ask for help. I think the message mentioning '\q' instead of 'quit' is important anyway since it works even on a dirty buffer. And experienced users already set their status lines anyway, so they would have an extra status space on the right for general things; perhaps RPROMPT, as zsh calls it. I'd rather have SO fill with "how to change the right prompt in psql" than "how to quit psql" since then we're talking about different user profiles. Tureba - Arthur Nascimento
On Tue, Dec 12, 2017 at 1:02 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
There is also stackexchange question with 51000 views that asks how to
start the postgresql client. Should we rename psql to mysql to help
new users too?
No, we shouldn't but it will help a lot is postgres client have names like "postgres", "postgres-client" or "portgres-sql". Even pgsql is better than psql. On mysql normally you type mysql then tab and bash show all mysql tools.
Ctrl-D works almost everywhere. It takes 2 seconds to find the answer
and there are going to be many other things you have to find out if
you're coming at PostgreSQL from a different DB.
Not everybody knows CTRL-D.
As others have pointed out, there are _far_ more frustrating things
(like the lack of SHOW CREATE [TABLE|etc]... support in the backend)
for anyone coming from mysql that I would suggest should be addressed
if you were serious about making life easier for those moving DBs.
Well theres lots of hungry people in the world, maybe we should stop improve software tool until everyone have food.
On 12 December 2017 at 16:39, Everaldo Canuto <everaldo.canuto@gmail.com> wrote: > On Tue, Dec 12, 2017 at 1:02 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: >> There is also stackexchange question with 51000 views that asks how to >> start the postgresql client. Should we rename psql to mysql to help >> new users too? > No, we shouldn't but it will help a lot is postgres client have names like > "postgres", "postgres-client" or "portgres-sql". Even pgsql is better than > psql. On mysql normally you type mysql then tab and bash show all mysql > tools. If you're going down _that_ route I'd vote for pg_sql since we have pg_dump and pg_ctl etc. But in order to know how to call those things you would still need to find out what they are. You think that typing mysql<tab> is "natural" but you only know how to do it because someone told you to type "mysql" to run the client. > Not everybody knows CTRL-D. And it takes two seconds to find the answer if you don't. Adding "quit" and/or "exit" would save each person a maximum of one web search per lifetime and would just confuse the paradigm that backslashed commands are handled by the client. > Well theres lots of hungry people in the world, maybe we should stop improve > software tool until everyone have food. That's a nonsense metaphor. If you said "there's lots of hungry people in the world, maybe we should stop bakers making croissants until everyone has bread" it might be slightly more appropriate. Geoff
On Tue, Dec 12, 2017 at 2:39 PM, Everaldo Canuto <everaldo.canuto@gmail.com> wrote:
As others have pointed out, there are _far_ more frustrating things
(like the lack of SHOW CREATE [TABLE|etc]... support in the backend)
for anyone coming from mysql that I would suggest should be addressed
if you were serious about making life easier for those moving DBs.Well theres lots of hungry people in the world, maybe we should stop improve software tool until everyone have food.
On 12 December 2017 at 16:36, Arthur Nascimento <tureba@gmail.com> wrote: > Nano keeps a cheatsheet of commands on the bottom; and it's regarded > as a fairly good editor for newcomers. Some shells have a right-hand > side status bar. I quite like this idea, although I would rather a line printed after each command is run: something like mydbname=# select ; -- (1 row) \h for help, \q for quit, \expert to turn off this message osprey=# This has the advantage that it doesn't need curses support, is pretty simple and actually has the "off" information inline. When you type \expert you could print a line that says put \expert in ~/.psqlrc to make this change permanent or something. Geoff
On 12/12/2017 12:00 PM, Geoff Winkless wrote: > I quite like this idea, although I would rather a line printed after > each command is run: something like > > mydbname=# select ; > -- > (1 row) > > \h for help, \q for quit, \expert to turn off this message > osprey=# It seems to me that this is very close to the Robert Haas suggestion already discussed upthread, except that suggestion only prints the hint message when you might need it, which I'd find less intrusive. -Chap
On 12 December 2017 at 18:32, Chapman Flack <chap@anastigmatix.net> wrote: > It seems to me that this is very close to the Robert Haas suggestion > already discussed upthread, except that suggestion only prints the > hint message when you might need it, which I'd find less intrusive. Well "close" yes, but I like "simpler", and I'm not sure I like the idea of waiting for someone to flail at the quit command before giving them a hint. Also, to be frank, if someone's typed "quit<cr>" and you're going to perform an action based on it, it feels like you might as well quit - a bit like google saying "did you mean \q" in its sneering supercilious way. Geoff
On Tue, Dec 12, 2017 at 10:02 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: > There is also stackexchange question with 51000 views that asks how to > start the postgresql client. Should we rename psql to mysql to help > new users too? That's not a serious question, and I don't know what your point is in suggesting it, unless it's that you want to just troll everyone, which I don't find especially constructive. > Ctrl-D works almost everywhere. It takes 2 seconds to find the answer > and there are going to be many other things you have to find out if > you're coming at PostgreSQL from a different DB. If it really took everyone 2 seconds, this question would not be as common as it is. So, it probably takes some people quite a bit longer. > As others have pointed out, there are _far_ more frustrating things > (like the lack of SHOW CREATE [TABLE|etc]... support in the backend) > for anyone coming from mysql that I would suggest should be addressed > if you were serious about making life easier for those moving DBs. That is neither a reason to make a change along the lines discussed here nor a reason not to do so. You can start separate threads about those other topics if you wish. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Dec 12, 2017 at 11:58 AM, Everaldo Canuto <everaldo.canuto@gmail.com> wrote: > Sorry to be so sarcastic on last comment but, I am a little frustrated, it > is not like this patch is big and need a lots of review, it is already done > and it takes 15 minutes from me and it was the first time I look at Postgres > source code. Really sorry. It's not really done in any useful sense, because it has a -1 vote from a prominent committer. There is however an alternative proposal which has several +1 votes, including from that same committer and from me. If you would like to produce a patch that implements that counter-proposal, it might go somewhere. Very little of significance gets done around here without some give and take; I know that's sometimes frustrating, but it's how it is. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Dec 12, 2017 at 3:38 PM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: > Well "close" yes, but I like "simpler", and I'm not sure I like the > idea of waiting for someone to flail at the quit command before giving > them a hint. I think a patch that adds a line to every prompt for everyone all the time and has to be explicitly turned off is not something that most people here are going to be willing to consider. -1 from me, for a start. > Also, to be frank, if someone's typed "quit<cr>" and you're going to > perform an action based on it, it feels like you might as well quit - > a bit like google saying "did you mean \q" in its sneering > supercilious way. Well, I don't agree; the reasons why have already been discussed upthread, so I won't repeat them here. Also, I think you're attributing a lot of emotion to Google's auto-correct. While it is not without its flaws, it is right about what I meant more often than it is wrong, and there are a lot of people who are worse at spelling than I am (not that I'm perfect or anything). Accuracy aside, I am fairly sure that it is an emotionless software artifact incapable either of sneering or superciliousness. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 12/12/2017 03:39 PM, Robert Haas wrote: > On Tue, Dec 12, 2017 at 10:02 AM, Geoff Winkless <pgsqladmin@geoff.dj> >> Ctrl-D works almost everywhere. It takes 2 seconds... > > If it really took everyone 2 seconds, this question would not be as > common as it is. ... Some years ago, I took a job at a mostly-Unix shop, where the default .profile supplied with every new account contained stty eof ^Z ... apparently, a sysadmin had liked the DOS convention better than the Unix one, and then made it the default for everybody. It often took people more than 2 seconds to learn to use ^Z where they expected ^D to work (not to mention to learn why they couldn't suspend). I guess I only mention that to reinforce the point that some environments have customizations you wouldn't expect, and assumptions about how obvious something is can be thrown off by a variety of things. -Chap
On Wed, Dec 13, 2017 at 5:42 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Dec 12, 2017 at 11:58 AM, Everaldo Canuto > <everaldo.canuto@gmail.com> wrote: >> Sorry to be so sarcastic on last comment but, I am a little frustrated, it >> is not like this patch is big and need a lots of review, it is already done >> and it takes 15 minutes from me and it was the first time I look at Postgres >> source code. Really sorry. > > It's not really done in any useful sense, because it has a -1 vote > from a prominent committer. There is however an alternative proposal > which has several +1 votes, including from that same committer and > from me. If you would like to produce a patch that implements that > counter-proposal, it might go somewhere. Very little of significance > gets done around here without some give and take; I know that's > sometimes frustrating, but it's how it is. Everaldo, please note that rewriting a patch happens quite a lot depending on the review feedback. This can happen even several times during one review process, and sometimes for patches way larger than that. Feeling frustrated is normal the first times you submit a patch, but that experience is part of getting more familiar with the community review process. That's why by beginning with smaller patches, as you do, is a good way to understand how things move on and why the code quality remains high. -- Michael
On 12 December 2017 at 23:02, Geoff Winkless <pgsqladmin@geoff.dj> wrote:
I wouldn't exactly say -1 but it's a "meh" from me.
On 8 December 2017 at 13:57, Daniel Vérité" <daniel@manitou-mail.org> wrote:
> "How to exit from PostgreSQL command line utility: psql"
>
> now at 430k views and 1368 upvotes.
There is also stackexchange question with 51000 views that asks how to
start the postgresql client. Should we rename psql to mysql to help
new users too?
Frankly, that's a legit question and I don't think it's one we should be mocking. The application is "PostgreSQL" and it's not at all surprising that people don't find it immediately obvious that the client is "psql". Yes, we have a manual, but if they have to refer to it for something that trivial then that's an opportunity for us to improve UX.
Especially since "postgres" isn't on the PATH in most installs.
I'd suggest having 'postgres' print a help msg suggesting "the client program is psql"... but that does no good if you get
$ postgres
bash: postgres: command not found...
Install package 'postgresql-server' to provide command 'postgres'? [N/y]
(then there's the Ubuntu versions that "helpfully" suggest you might want to install postgres-xc. Seriously. WTF, people.)
Ctrl-D works almost everywhere.
... if you are used to using a command line interface and know it even exists.
It takes 2 seconds to find the answer
and there are going to be many other things you have to find out if
you're coming at PostgreSQL from a different DB.
Yep. But that doesn't mean we should make the simple things harder than they need to be. Why have \? at all!
As others have pointed out, there are _far_ more frustrating things
(like the lack of SHOW CREATE [TABLE|etc]... support in the backend)
I cannot overemphasise the importance of that one. I don't care that much about the spelling, tbh, but the fact that table metadata formatting and display is done wholly client-side and cannot be used in applications is absolutely horrid, and a real wart in the system. If we had the server-side functionality then some special case HINTs in error messages for common systems would be reasonable enough.
Frankly that's probably a good idea anyway, adding a specific errhint. But it's really a separate topic.
On 12 December 2017 at 23:28, Avinash Kumar <avinash.vallarapu@gmail.com> wrote:
It takes a few hours to learn PostgreSQL and 1 second to remember, how to quit from psql.Surprised to see the depth of discussion on this.He knows about psql because he searched it somewhere. Just a psql --help (anybody uses help), should help me know much more about psql.It takes sometime for a person to explore or know about PostgreSQL and install it.Likewise, it takes him some more time to understand that there exists a "psql" to connect to it.I think many people doesn't find it difficult to quit using \q.I think its good to talk about or help with more features that helps a production database.
It's easy to dismiss usability concerns, but new users are what keeps a community healthy. Users who go "WTF is this @#$@" and bail aren't necessarily the ones you want to lose; sometimes they're just busy or are evaluating a few things at once. Early UX matters.
There is also stackexchange question with 51000 views that asks how to
start the postgresql client. Should we rename psql to mysql to help
new users too?Frankly, that's a legit question and I don't think it's one we should be mocking. The application is "PostgreSQL" and it's not at all surprising that people don't find it immediately obvious that the client is "psql". Yes, we have a manual, but if they have to refer to it for something that trivial then that's an opportunity for us to improve UX.Especially since "postgres" isn't on the PATH in most installs.I'd suggest having 'postgres' print a help msg suggesting "the client program is psql"... but that does no good if you get
This seems like a somewhat easy one to solve...add "postgresql" "postgres" "postgre" "pgsql" "theelephantdb" "sql" and whatever other names we think come to people's minds and place them in the client bin directory right next to psql. Have them do something useful - either the equivalent of "exec psql" or "echo 'use psql to invoke the client'". Make it a compile-time option so package maintainers who disagree (or place postgres server in the path) can opt-out (or opt-in) - but at least not every packager would need to write their own. That said, I consider this particular aliasing problem to be a packaging problem and not the responsibility of core.
David J.
I'm not sure what the usual shape of 'consensus' or 'resolution' is in these things, but it seems to me that the branch of this email thread that leads here (through the message from Robert that I'm replying to) is the one that felt like it was converging. I thought it was converging on the idea that ^[whitespace]*(quit|exit)[whitespace]*(;[whitespace]*)?$ would be treated specially when interactive, whether on a first or a continuation line, and that the special treatment would be a helpful explanatory message to the interactive user, while nevertheless appending the text to the query buffer. One possibly not-yet-converged point was whether the special treatment should be the same on a first line, or should just actually quit in that case. None of this is what the currently latest patch does, though. -Chap
Chapman Flack <chap@anastigmatix.net> writes:
> I'm not sure what the usual shape of 'consensus' or 'resolution' is in these things,
> but it seems to me that the branch of this email thread that leads here (through the
> message from Robert that I'm replying to) is the one that felt like it was converging.
> I thought it was converging on the idea that
> ^[whitespace]*(quit|exit)[whitespace]*(;[whitespace]*)?$
> would be treated specially when interactive, whether on a first or a continuation line,
> and that the special treatment would be a helpful explanatory message to the
> interactive user, while nevertheless appending the text to the query buffer.
That's what I thought, too. I also think that we should recognize "help"
under exactly the same circumstances --- right now only a subset of what
you specify here will trigger the help response.
> One possibly not-yet-converged point was whether the special treatment should
> be the same on a first line, or should just actually quit in that case.
I can get on board with actually quitting if it's on the first line,
which is equivalent to the current behavior for "help". That is,
all three would do-what-it-says-on-the-tin if entered when the query
buffer is empty, while they'd all emit an explanatory message (maybe
the same for all three, or maybe not) if entered when the query
buffer is not empty.
I doubt we have consensus on just what the explanatory message should
say, but maybe the author can give us a proposal to shoot at.
regards, tom lane
Change my patch will make psql different from other sql clients I use (sqlplus and mysql).
I am happy with my custom version of psql so you can cancel/delete/ignore my patch.
On Sun, Jan 7, 2018 at 12:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Everaldo Canuto <everaldo.canuto@gmail.com> writes:
> Can we proceed with current behavior and change some day when we have a
> consensus of a better way to handle this and then change quit/exit and help
> together?
I think it's quite clear that there is *not* a consensus for your
patch as submitted. Please adjust it as per this discussion.
regards, tom lane
Everaldo Canuto
+55 11 953-908-387 | everaldo.canuto@gmail.com
01100101 01110110 01100101 01110010
01100001 01101100 01100100 01101111
+55 11 953-908-387 | everaldo.canuto@gmail.com
01100101 01110110 01100101 01110010
01100001 01101100 01100100 01101111
Everaldo Canuto wrote: > Change my patch will make psql different from other sql clients I use > (sqlplus and mysql). Well, I don't think we're too hot about copying their behavior exactly. This thread discussed the behavior at length and a consensus was found after much thinking. No one is imposing anything. > I am happy with my custom version of psql so you can cancel/delete/ignore > my patch. We're not happy to lose a potential contributor, but of course that's your prerogative. Can we find somebody else willing to implement the agreed-upon behavior? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 01/09/2018 02:29 AM, Alvaro Herrera wrote: > Everaldo Canuto wrote: >> Change my patch will make psql different from other sql clients I use >> (sqlplus and mysql). > > Well, I don't think we're too hot about copying their behavior exactly. > This thread discussed the behavior at length and a consensus was found > after much thinking. No one is imposing anything. > >> I am happy with my custom version of psql so you can cancel/delete/ignore >> my patch. > > We're not happy to lose a potential contributor, but of course that's > your prerogative. > > Can we find somebody else willing to implement the agreed-upon behavior? I'm currently reviewing two other patches in the commitfest (in my limited time). When I'm done with those I would be happy to pick this up if no one else has. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Vik, all, * Vik Fearing (vik.fearing@2ndquadrant.com) wrote: > On 01/09/2018 02:29 AM, Alvaro Herrera wrote: > > Everaldo Canuto wrote: > >> Change my patch will make psql different from other sql clients I use > >> (sqlplus and mysql). > > > > Well, I don't think we're too hot about copying their behavior exactly. > > This thread discussed the behavior at length and a consensus was found > > after much thinking. No one is imposing anything. > > > >> I am happy with my custom version of psql so you can cancel/delete/ignore > >> my patch. > > > > We're not happy to lose a potential contributor, but of course that's > > your prerogative. > > > > Can we find somebody else willing to implement the agreed-upon behavior? > > I'm currently reviewing two other patches in the commitfest (in my > limited time). When I'm done with those I would be happy to pick this > up if no one else has. Looks like the status of this should really be 'waiting on author' (even if the current author isn't really interested in updating it, sounds like Vik might be), so I've adjusted its status. I'm also of the opinion that this would be good to have, though I don't know that I'll have time to bring it over the line for v11. Thanks! Stephen
Attachment
On 01/13/2018 10:52 PM, Stephen Frost wrote: > Vik, all, > > * Vik Fearing (vik.fearing@2ndquadrant.com) wrote: >> On 01/09/2018 02:29 AM, Alvaro Herrera wrote: >>> Everaldo Canuto wrote: >>>> Change my patch will make psql different from other sql clients I use >>>> (sqlplus and mysql). >>> >>> Well, I don't think we're too hot about copying their behavior exactly. >>> This thread discussed the behavior at length and a consensus was found >>> after much thinking. No one is imposing anything. >>> >>>> I am happy with my custom version of psql so you can cancel/delete/ignore >>>> my patch. >>> >>> We're not happy to lose a potential contributor, but of course that's >>> your prerogative. >>> >>> Can we find somebody else willing to implement the agreed-upon behavior? >> >> I'm currently reviewing two other patches in the commitfest (in my >> limited time). When I'm done with those I would be happy to pick this >> up if no one else has. > > Looks like the status of this should really be 'waiting on author' (even > if the current author isn't really interested in updating it, sounds > like Vik might be), so I've adjusted its status. > > I'm also of the opinion that this would be good to have, though I don't > know that I'll have time to bring it over the line for v11. After re-reading the thread, I think the original patch is optimal. I don't like what the consensus is and so I have no interest in implementing it. In particular, I currently hate how pasting a query with tabs screws everything up with unhelpful completions. I don't want to add to that with the column example Tom exposed in [1] and especially with the plpgsql example Vladimir Svedov exposed in [2]. I quite like the idea of blanking the database name in PROMPT2 as suggested by Daniel in [3], I would be happy to work on that patch if others agree. [1] https://postgr.es/m/31478.1512760025@sss.pgh.pa.us [2] https://postgr.es/m/CADqDLE-hgRA0qLeiC3a3DJ41-yR5kj=k0o679K=zk32VLzaB1Q@mail.gmail.com [3] https://postgr.es/m/ad75eab6-71ea-4e1f-8aa5-68876ff50651@manitou-mail.org -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Vik, * Vik Fearing (vik.fearing@2ndquadrant.com) wrote: > On 01/13/2018 10:52 PM, Stephen Frost wrote: > > * Vik Fearing (vik.fearing@2ndquadrant.com) wrote: > >> On 01/09/2018 02:29 AM, Alvaro Herrera wrote: > >>> Everaldo Canuto wrote: > >>>> Change my patch will make psql different from other sql clients I use > >>>> (sqlplus and mysql). > >>> > >>> Well, I don't think we're too hot about copying their behavior exactly. > >>> This thread discussed the behavior at length and a consensus was found > >>> after much thinking. No one is imposing anything. > >>> > >>>> I am happy with my custom version of psql so you can cancel/delete/ignore > >>>> my patch. > >>> > >>> We're not happy to lose a potential contributor, but of course that's > >>> your prerogative. > >>> > >>> Can we find somebody else willing to implement the agreed-upon behavior? > >> > >> I'm currently reviewing two other patches in the commitfest (in my > >> limited time). When I'm done with those I would be happy to pick this > >> up if no one else has. > > > > Looks like the status of this should really be 'waiting on author' (even > > if the current author isn't really interested in updating it, sounds > > like Vik might be), so I've adjusted its status. > > > > I'm also of the opinion that this would be good to have, though I don't > > know that I'll have time to bring it over the line for v11. > > After re-reading the thread, I think the original patch is optimal. I > don't like what the consensus is and so I have no interest in > implementing it. > > In particular, I currently hate how pasting a query with tabs screws > everything up with unhelpful completions. I don't want to add to that > with the column example Tom exposed in [1] and especially with the > plpgsql example Vladimir Svedov exposed in [2]. The issue expressed in [1] was pretty clearly addressed, imv, by only printing out a message instead of actually aborting things as suggested later by Robert. That seem approach can be used to deal with the plpgsql 'exit;' case mentioned in your [2]. > I quite like the idea of blanking the database name in PROMPT2 as > suggested by Daniel in [3], I would be happy to work on that patch if > others agree. I'm not against that as it's largely orthogonal and seems pretty reasonable by itself. I don't know that having it really takes anything away from having help/quit/exit be detected by psql and a message sent back to the user that maybe they are looking for help. If this is picked up by psql then we can also do things like *not* throw the message out there when we know what we're working with is from a \ef or similar, so this would only happen if you're actually pasting some big function in that happens to have 'exit;' in it, and then you get a message back, but otherwise the function definition works just fine and you can ignore it and move on... Maybe we should have a \pset parameter to disable this too, so that people who really don't have to see the warnings kicked back have a way to get rid of them. That certainly seems like it'd be pretty simple to do and something we could include in the help output... Thanks! Stephen
Attachment
Vik Fearing <vik.fearing@2ndquadrant.com> writes:
> After re-reading the thread, I think the original patch is optimal.
Hm, few other people thought that.
> In particular, I currently hate how pasting a query with tabs screws
> everything up with unhelpful completions. I don't want to add to that
> with the column example Tom exposed in [1] and especially with the
> plpgsql example Vladimir Svedov exposed in [2].
That seems like sort of an independent problem, though. I wonder
whether it's possible to find out from libreadline that the input
text came from a paste rather than being typed.
> I quite like the idea of blanking the database name in PROMPT2 as
> suggested by Daniel in [3], I would be happy to work on that patch if
> others agree.
I think that the part of that about inserting a line number is important.
What about combining the two ideas: in PROMPT2, the database name is
*replaced* by a line number, while (trying to) keep the width the same?
regards, tom lane
Tom, Vik, all, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Vik Fearing <vik.fearing@2ndquadrant.com> writes: > > In particular, I currently hate how pasting a query with tabs screws > > everything up with unhelpful completions. I don't want to add to that > > with the column example Tom exposed in [1] and especially with the > > plpgsql example Vladimir Svedov exposed in [2]. > > That seems like sort of an independent problem, though. I wonder > whether it's possible to find out from libreadline that the input > text came from a paste rather than being typed. I'm not sure exactly how, but I know that some software is able to figure that out (irssi, in particular). Might be just a timing-based heuristic though. > > I quite like the idea of blanking the database name in PROMPT2 as > > suggested by Daniel in [3], I would be happy to work on that patch if > > others agree. > > I think that the part of that about inserting a line number is important. > What about combining the two ideas: in PROMPT2, the database name is > *replaced* by a line number, while (trying to) keep the width the same? Seems like a good approach to me. Thanks! Stephen
Attachment
On Sat, Jan 13, 2018 at 11:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Vik Fearing <vik.fearing@2ndquadrant.com> writes:
> After re-reading the thread, I think the original patch is optimal.
Hm, few other people thought that.
I don't wanna be irritating but here every postgres user I found really can't understand how the original patch was not accepted, people against it did not show good reasons.
> In particular, I currently hate how pasting a query with tabs screws
> everything up with unhelpful completions. I don't want to add to that
> with the column example Tom exposed in [1] and especially with the
> plpgsql example Vladimir Svedov exposed in [2].
That seems like sort of an independent problem, though. I wonder
whether it's possible to find out from libreadline that the input
text came from a paste rather than being typed.
> I quite like the idea of blanking the database name in PROMPT2 as
> suggested by Daniel in [3], I would be happy to work on that patch if
> others agree.
I think that the part of that about inserting a line number is important.
What about combining the two ideas: in PROMPT2, the database name is
*replaced* by a line number, while (trying to) keep the width the same?
If you guys can review the supposed consensus about this patch, I can spend some time and implement this PROMPT2 idea on different patch submission.
Regards, Everaldo
On 01/13/18 21:36, Everaldo Canuto wrote: > I don't wanna be irritating but here every postgres user I found really > can't understand how the original patch was not accepted, people against it > did not show good reasons. As I was watching this thread go by, the reasons being shown seemed good to me, and they were being raised by some of the people most responsible (as one quickly learns by scanning old archives), over the years, for postgres being the excellent thing that it is, so it would not be my first instinct to dismiss them. One of the things I have come to really appreciate about this community (in which I am still a relative newcomer) is that when disagreements arise, you can see them being worked through by consideration of technical points and somewhat measurable principles. In that light, if there's a better conclusion you think is worth advocating, that would fit right in if done in ways that respond to, and address in some way, the points already raised; that adds more to the conversation than just saying they were not "good". -Chap
On Sun, Jan 14, 2018 at 2:38 AM, Chapman Flack <chap@anastigmatix.net> wrote:
On 01/13/18 21:36, Everaldo Canuto wrote:
> I don't wanna be irritating but here every postgres user I found really
> can't understand how the original patch was not accepted, people against it
> did not show good reasons.
As I was watching this thread go by, the reasons being shown seemed good
to me, and they were being raised by some of the people most responsible
(as one quickly learns by scanning old archives), over the years, for
postgres being the excellent thing that it is, so it would not be my
first instinct to dismiss them.
Yes, your are right and I Postgres is the best database in my opinion and it tells me that community here must be responsible. I just think that Postgres could be a little more friendly, it is really hard to me to see my customers choosing other databases because they feel Postgres is hard, I end up loosing amazing Postgres features.
Unfortunately you are right, my first instinct was to dismiss them and it could be a problem on my side but as I said previously on this thread, it is really frustrating for me to see a so small patch that "fix" one of new comers problem (also casual users and user of multiple databases) and don't hurts anything in PG end up on a directions that makes the problem even worst. Also I don't see a consensus on this thread and I don't understand how decisions are taken.
Again, maybe the problem is with me but is a fact that people feel like Postgres is hard.
Since it is my last message to this thread (I don't think my words will convince anyone) let me explain how came here: I was attending a conference with a friend who is also the owner of a Postgres support company and we start to discuss some small problems that could be relatively easy to fix and could make Postgres even better. At some point he just point why a experienced C developer like me (we would love to develop in C) don't contribute to the project and we came up with a list of things to improve and I decide to make a test with something simple and fast to implement to test if Postgres is not like a GNOME community. So, here I am.
One of the things I have come to really appreciate about this community
(in which I am still a relative newcomer) is that when disagreements arise,
you can see them being worked through by consideration of technical points
and somewhat measurable principles. In that light, if there's a better
conclusion you think is worth advocating, that would fit right in if done
in ways that respond to, and address in some way, the points already
raised; that adds more to the conversation than just saying they were
not "good".
-Chap
You are right again and could be something wrong with my side, I really can't see the arguments agains as good, they look me like a personal taste and not technical. I through that even my arguments or people that agree with this patch is also more a personal opinion than technical but I think it will not hurt if we made Postgres more friendly to newcomers.
What is really funny is that I was prepared for long and hard discussions on future because but not on this. On my list of next patches was:
* SHOW TABLES
* DES[CRIBE]
* SEARCH path environment var for \i and \ir (it is really useful)
* Changes on pg_hba default values so local sql clients can connect without change it
* and so on...
* and so on...
Anyway, sorry if I offended someone, It is not my intention.
Keep the good work guys and even if PG is the best, maybe take some look at MariaDB will not hurt too much ;-)
Regards.
Everaldo Canuto wrote: > Also I don't see a consensus on this thread and I don't understand how decisions are taken. It's just difficult to find consensus with many people. There were several valid concerns with this, the most striking (to me) was Tome's concern that there are perfectly valid multi-line SQL statements where a line could start with "exit" or "quit". Robert Haas had an idea how to provide useful hints without breaking anything, but it seemed a little complicated. There was some discussion whether the lack of "quit" or "exit" is a real problem or not, but most people could share your view that it would be good to improve the newcomers' experience. Consensus is never reached explicitly, rather implicitly through positive feedback and a lack of concerns. Everybody can have an opinion, but in a "meritocracy" like this not all opinions are equal. If a "notable" contributor has an objection, and no person of equal standing disagrees, you have to either address the concerns or consider the proposal rejected. If you see a way forward, describe it to attract further feedback. If you feel that you have enough buy-in, you can add the patch to the next commitfest. The ultimate test is then if you can attract reviewers that examine your patch and committers that are willing to spend time to commit it. I am aware that this process can be quite tiresome and discouraging, but any patch that makes it through will be much improved by it. Yours, Laurenz Albe
On Mon, Jan 15, 2018 at 7:28 AM, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > Everaldo Canuto wrote: >> Also I don't see a consensus on this thread and I don't understand how decisions are taken. > > It's just difficult to find consensus with many people. > > There were several valid concerns with this, the most striking (to me) > was Tome's concern that there are perfectly valid multi-line SQL statements > where a line could start with "exit" or "quit". > > Robert Haas had an idea how to provide useful hints without breaking anything, > but it seemed a little complicated. It's not really that complicated. Here's a patch. This follows what Tom suggested in http://postgr.es/m/30157.1513058300@sss.pgh.pa.us and what I suggested in https://www.postgresql.org/message-id/CA%2BTgmoZswp00PtcgPfQ9zbbh7HUTgsLLJ9Z1x9E2s8Y7ep048g%40mail.gmail.com I've discovered one thing about this design that is not so good, which is that if you open a single, double, or dollar quote, then the instructions that are provided under that design do not work: rhaas=# select $$ rhaas$# quit Use \q to quit or press control-C to clear the input buffer. rhaas$# \q rhaas$# well this sucks rhaas$# Obviously this leaves something to be desired, but I think it's probably just a matter of rephrasing the hint somehow. I didn't have a good idea off-hand though, so here's the patch as I have it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Attachment
Robert, * Robert Haas (robertmhaas@gmail.com) wrote: > On Mon, Jan 15, 2018 at 7:28 AM, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > Everaldo Canuto wrote: > >> Also I don't see a consensus on this thread and I don't understand how decisions are taken. > > > > It's just difficult to find consensus with many people. > > > > There were several valid concerns with this, the most striking (to me) > > was Tome's concern that there are perfectly valid multi-line SQL statements > > where a line could start with "exit" or "quit". > > > > Robert Haas had an idea how to provide useful hints without breaking anything, > > but it seemed a little complicated. > > It's not really that complicated. Here's a patch. This follows what > Tom suggested in http://postgr.es/m/30157.1513058300@sss.pgh.pa.us and > what I suggested in > https://www.postgresql.org/message-id/CA%2BTgmoZswp00PtcgPfQ9zbbh7HUTgsLLJ9Z1x9E2s8Y7ep048g%40mail.gmail.com > > I've discovered one thing about this design that is not so good, which > is that if you open a single, double, or dollar quote, then the > instructions that are provided under that design do not work: > > rhaas=# select $$ > rhaas$# quit > Use \q to quit or press control-C to clear the input buffer. > rhaas$# \q > rhaas$# well this sucks > rhaas$# > Obviously this leaves something to be desired, but I think it's > probably just a matter of rephrasing the hint somehow. I didn't have > a good idea off-hand though, so here's the patch as I have it. Well, control-C would still work in that case, so I'm not sure that it's so bad. It's certainly better than what we have now. I would have thought to include a hint to use \? for help too but it might make the hint too long. How about putting control-C first, like this?: Press control-C to abort a command, \q to quit, or \? for help Thanks! Stephen
Attachment
Robert Haas <robertmhaas@gmail.com> writes:
> I've discovered one thing about this design that is not so good, which
> is that if you open a single, double, or dollar quote, then the
> instructions that are provided under that design do not work:
I was kind of imagining that we could make the hint text vary depending
on the parsing state. Maybe that's too hard to get to --- but if the
prompt-creating code knows what it is, perhaps this can too.
regards, tom lane
On Mon, Jan 15, 2018 at 10:48 AM, Stephen Frost <sfrost@snowman.net> wrote: > Well, control-C would still work in that case, so I'm not sure that it's > so bad. It's certainly better than what we have now. I would have > thought to include a hint to use \? for help too but it might make the > hint too long. How about putting control-C first, like this?: > > Press control-C to abort a command, \q to quit, or \? for help One problem with this (and to some extent also with my version) is that it doesn't really make it entirely clear that aborting a command (or in the case of my version, clearing the input buffer) is something you really ought to think about doing. You might see that message and not quite realize that there is a command in progress; if that weren't an issue, we wouldn't need to print anything here at all. It's almost like we want to say something along the lines of "Hey there, interactive user! What you just typed looked suspiciously like a command but, because there is text in the query buffer, I didn't treat it as one and printed this ridiculously long blurb instead. If you want me to treat it as a command, press ^C to clear the query buffer and then type that same thing again. Thanks!" However, that's a bit long and, while there are some obvious ways to shorten it somewhat, I can't really think of an overall phrasing that fits into an 80-character line without losing clarity. The other point I would make is that, while I agree with you that the patch is an improvement over the status quo, I'm not really keen to print a message telling people to use \q or \? when in fact that those things might not work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Jan 15, 2018 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I've discovered one thing about this design that is not so good, which >> is that if you open a single, double, or dollar quote, then the >> instructions that are provided under that design do not work: > > I was kind of imagining that we could make the hint text vary depending > on the parsing state. Maybe that's too hard to get to --- but if the > prompt-creating code knows what it is, perhaps this can too. prompt_status does seem to be available in psql's MainLoop(), so I think that could be done, but the problem is that I don't know exactly what message would be useful to print when we're in a "in quotes" state. If I had a good message text for that state, I might just choose to use it always rather than multiplying the number of messages. More broadly, I think what is needed here is less C-fu than English-fu. If we come up with something good, we can make it print that thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 15 January 2018 at 16:10, Robert Haas <robertmhaas@gmail.com> wrote: > > More broadly, I think what is needed here is less C-fu than > English-fu. If we come up with something good, we can make it print > that thing. > Can we not just say "ctrl-D to quit" instead of \q? Doesn't that work everywhere? Geoff
Geoff Winkless wrote: > Can we not just say "ctrl-D to quit" instead of \q? Doesn't that work > everywhere? Not on Windows, as far as I know. Yours, Laurenz Albe
Geoff, all, * Geoff Winkless (pgsqladmin@geoff.dj) wrote: > On 15 January 2018 at 16:10, Robert Haas <robertmhaas@gmail.com> wrote: > > > > More broadly, I think what is needed here is less C-fu than > > English-fu. If we come up with something good, we can make it print > > that thing. > > Can we not just say "ctrl-D to quit" instead of \q? Doesn't that work > everywhere? My favorite part of this thread so far is actually realizing that when someone hits ctrl-D, we'll happily print '\q' even if we were in quotes: => select $$ -> oh look -> \q -> doesn't work -> but if I hit ctrl-D... -> \q ➜ ~ Which is pretty cute considering \q doesn't actually work there. :) Thanks! Stephen
Attachment
On 15 January 2018 at 16:16, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > Geoff Winkless wrote: >> Can we not just say "ctrl-D to quit" instead of \q? Doesn't that work >> everywhere? > > Not on Windows, as far as I know. Well on Windows, Ctrl-C doesn't clear the input buffer either - it quits the whole thing. Perhaps different messages on different OSes? :) Others point out (elsewhere) that Ctrl-D fails if there's anything before it on the individual line, which is news to me. Is that a readline thing? Geoff
Geoff Winkless <pgsqladmin@geoff.dj> writes:
> Perhaps different messages on different OSes? :)
It's worse than that: the EOF key is configurable. In principle we
could look into the tty settings and print the right thing, but
I doubt we want to go there, especially if there's no corresponding
thing on Windows.
regards, tom lane
On 15 January 2018 at 16:48, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Geoff Winkless <pgsqladmin@geoff.dj> writes: >> Perhaps different messages on different OSes? :) > > It's worse than that: the EOF key is configurable. In principle we > could look into the tty settings and print the right thing, but > I doubt we want to go there, especially if there's no corresponding > thing on Windows. But surely if Windows always exits using Ctrl-C than that's easiest? And while trying to find the EOF setting in libreadline might get messy, you're already assuming that ctrl-C hasn't been knobbled using stty intr. Unless you want to go searching for that too? Geoff
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 15, 2018 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I was kind of imagining that we could make the hint text vary depending
>> on the parsing state. Maybe that's too hard to get to --- but if the
>> prompt-creating code knows what it is, perhaps this can too.
> More broadly, I think what is needed here is less C-fu than
> English-fu. If we come up with something good, we can make it print
> that thing.
Right, but if we're willing to look at the parse state, we don't need
to cram all possible knowledge into one 80-character string. I'm
thinking about just responding to the current situation, say
You have begun a quoted string. To end it, type '
(or ", or $foo$ as appropriate). I'm inclined to violate our usual
message style guidelines here by not putting any quotes or punctuation
around the ending quote ... more likely to confuse than help.
Or, if you're not in a string but there's text in the buffer,
You have entered an incomplete SQL command.
Type ; to send it or \r to discard it.
Or, if there's no text in the buffer, we print the existing help
message for "help", or just exit for quit/exit.
regards, tom lane
On Mon, Jan 15, 2018 at 04:53:27PM +0000, Geoff Winkless wrote: > On 15 January 2018 at 16:48, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Geoff Winkless <pgsqladmin@geoff.dj> writes: > >> Perhaps different messages on different OSes? :) > > > > It's worse than that: the EOF key is configurable. In principle > > we could look into the tty settings and print the right thing, but > > I doubt we want to go there, especially if there's no > > corresponding thing on Windows. > > But surely if Windows always exits using Ctrl-C than that's easiest? > > And while trying to find the EOF setting in libreadline might get > messy, you're already assuming that ctrl-C hasn't been knobbled > using stty intr. Unless you want to go searching for that too? I'm pretty sure changing either or both of those settings would qualify as pilot error, and pretty abstruse pilot error at that. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Geoff Winkless <pgsqladmin@geoff.dj> writes:
> And while trying to find the EOF setting in libreadline might get
> messy, you're already assuming that ctrl-C hasn't been knobbled using
> stty intr. Unless you want to go searching for that too?
Yeah, that's why I personally don't want to mention ctrl-C in this
message. If we do mention it we're going to need to look up what
the signal is really bound to.
regards, tom lane
On 15 January 2018 at 16:56, David Fetter <david@fetter.org> wrote: > On Mon, Jan 15, 2018 at 04:53:27PM +0000, Geoff Winkless wrote: >> And while trying to find the EOF setting in libreadline might get >> messy, you're already assuming that ctrl-C hasn't been knobbled >> using stty intr. Unless you want to go searching for that too? > > I'm pretty sure changing either or both of those settings would > qualify as pilot error, and pretty abstruse pilot error at that. Oh I agree. I was merely pointing out that the likelihood of one is no more than the other. In fact, I _have_ worked on systems (in the 90s, admittedly) where intr was mapped to the "Delete" key. I've never (to my knowledge) worked on a system where EOF was mapped to anything other than CTRL-D in a command-line context, although I can see that emacs obsessives might want to have configured their readline that way, which would stomp all over ctrl-D. It also occurs to me that if someone has just typed quit<cr> or exit<cr> space at the start-of-line should not be a problem for Ctrl-D, because the buffer is empty. I still think it (Ctrl-D on *nix, Ctrl-C on windows) is the best of a bad bunch, to be honest. Geoff On 15 January 2018 at 16:56, David Fetter <david@fetter.org> wrote: > On Mon, Jan 15, 2018 at 04:53:27PM +0000, Geoff Winkless wrote: >> On 15 January 2018 at 16:48, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > Geoff Winkless <pgsqladmin@geoff.dj> writes: >> >> Perhaps different messages on different OSes? :) >> > >> > It's worse than that: the EOF key is configurable. In principle >> > we could look into the tty settings and print the right thing, but >> > I doubt we want to go there, especially if there's no >> > corresponding thing on Windows. >> >> But surely if Windows always exits using Ctrl-C than that's easiest? >> >> And while trying to find the EOF setting in libreadline might get >> messy, you're already assuming that ctrl-C hasn't been knobbled >> using stty intr. Unless you want to go searching for that too? > > I'm pretty sure changing either or both of those settings would > qualify as pilot error, and pretty abstruse pilot error at that. > > Best, > David. > -- > David Fetter <david(at)fetter(dot)org> http://fetter.org/ > Phone: +1 415 235 3778 > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate
On 15 January 2018 at 17:03, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Geoff Winkless <pgsqladmin@geoff.dj> writes: >> And while trying to find the EOF setting in libreadline might get >> messy, you're already assuming that ctrl-C hasn't been knobbled using >> stty intr. Unless you want to go searching for that too? > > Yeah, that's why I personally don't want to mention ctrl-C in this > message. If we do mention it we're going to need to look up what > the signal is really bound to. Could always rewrite gets_interactive to implement the documented "alternative interface" to readline https://tiswww.cwru.edu/php/chet/readline/readline.html#SEC43 and force exit that way by intercepting Ctrl-D at the character level. That does feel a bit (!) wrong though, and I'm not sure how difficult it gets with different locales etc. Would also have to modify gets_fromFile, in case readline was disabled. At this point it depends quite how far down the rabbit-hole you want to go to stop people googling "how do I exit psql", I suppose :p Geoff
Geoff Winkless <pgsqladmin@geoff.dj> writes:
> At this point it depends quite how far down the rabbit-hole you want
> to go to stop people googling "how do I exit psql", I suppose :p
Well, I concur with Robert's comment upthread that we don't want to
print any advice that's possibly wrong. So I'd rather provide hints
that are sure to work, rather than hints that might represent the
way to get out with fewest keystrokes, but could go wrong in unusual
situations.
regards, tom lane
On 01/15/18 11:56, David Fetter wrote: >> And while trying to find the EOF setting in libreadline might get >> messy, you're already assuming that ctrl-C hasn't been knobbled >> using stty intr. Unless you want to go searching for that too? > > I'm pretty sure changing either or both of those settings would > qualify as pilot error, and pretty abstruse pilot error at that. I once worked in a shop where the EOF default had in fact been changed to ^Z on the Unix boxen, for consistency with Windows. I may have had a personal opinion about it not unlike yours, but the pilot at the time being my boss, I just made it my business to cheerfully explain it every. time. it. needed. explaining. So, it's a thing that can happen. -Chap
On Mon, January 15, 2018 11:10 am, Robert Haas wrote: > On Mon, Jan 15, 2018 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> I've discovered one thing about this design that is not so good, which >>> is that if you open a single, double, or dollar quote, then the >>> instructions that are provided under that design do not work: >> >> I was kind of imagining that we could make the hint text vary depending >> on the parsing state. Maybe that's too hard to get to --- but if the >> prompt-creating code knows what it is, perhaps this can too. > > prompt_status does seem to be available in psql's MainLoop(), so I > think that could be done, but the problem is that I don't know exactly > what message would be useful to print when we're in a "in quotes" > state. If I had a good message text for that state, I might just > choose to use it always rather than multiplying the number of > messages. > > More broadly, I think what is needed here is less C-fu than > English-fu. If we come up with something good, we can make it print > that thing. Maybe that's a Linux-specific thing, but I always use Ctrl-D to exit a console, and this works with psql, too, even when in the middle of a query typed. So maybe this could be suggested? Best wishes, Tels
Moin, On Mon, January 15, 2018 2:34 pm, Tels wrote: > Maybe that's a Linux-specific thing, but I always use Ctrl-D to exit a > console, and this works with psql, too, even when in the middle of a query > typed. > > So maybe this could be suggested? Sorry, should have really read the thread until the very end, please ignore my noise. Best wishes, Tels
On Mon, Jan 15, 2018 at 01:24:45PM -0500, Chapman Flack wrote: > On 01/15/18 11:56, David Fetter wrote: > >> And while trying to find the EOF setting in libreadline might get > >> messy, you're already assuming that ctrl-C hasn't been knobbled > >> using stty intr. Unless you want to go searching for that too? > > > > I'm pretty sure changing either or both of those settings would > > qualify as pilot error, and pretty abstruse pilot error at that. > > I once worked in a shop where the EOF default had in fact been changed > to ^Z on the Unix boxen, for consistency with Windows. I may have had > a personal opinion about it not unlike yours, but the pilot at the time > being my boss, I just made it my business to cheerfully explain it every. > time. it. needed. explaining. > > So, it's a thing that can happen. Of course it is. It's just not a thing I believe we should perturb our code or documentation to accommodate. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 01/15/18 16:32, David Fetter wrote: > On Mon, Jan 15, 2018 at 01:24:45PM -0500, Chapman Flack wrote: >> On 01/15/18 11:56, David Fetter wrote: >>>> And while trying to find the EOF setting in libreadline might get >>>> messy, you're already assuming that ctrl-C hasn't been knobbled >>>> using stty intr. Unless you want to go searching for that too? >> >> So, it's a thing that can happen. > > Of course it is. It's just not a thing I believe we should perturb > our code or documentation to accommodate. So ISTM that the best way to have code/documentation that (a) isn't perturbed, and (b) doesn't tell people things that might be wrong, would be (at least for this patch) to focus the help text on things PostgreSQL controls (you're in a quoted string, here's how to end it; you're in a multiline command, here's how to finish or reset it, etc.). *Maybe* it could speak vaguely about your end-of-file keystroke, or interrupt keystroke (there could well be a better way to say that), which would be good enough now for people who know what those are, and *maybe* that could be seen as opening the door to a future patch if someone wanted to code up OS-specific checks and add "(which seems to be ^D)", "(which seems to be ^Z)", etc. That would perturb the code a bit, but the decision whether that patch would be worthwhile could be deferred until there was someone interested in working on it. -Chap
On 15 January 2018 at 17:53, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Geoff Winkless <pgsqladmin@geoff.dj> writes: >> At this point it depends quite how far down the rabbit-hole you want >> to go to stop people googling "how do I exit psql", I suppose :p > > Well, I concur with Robert's comment upthread that we don't want to > print any advice that's possibly wrong. So I'd rather provide hints > that are sure to work, rather than hints that might represent the > way to get out with fewest keystrokes, but could go wrong in unusual > situations. A quick PoC. I should say upfront that I've no axe to grind over this, if no-one likes the idea I don't mind: I'm not sure I like it myself (it's quite an aggressive stance to take, I think) - I just wanted to see if it would work, and provide it as a working possibility. Basically, I intercept every keypress before we send it to readline. If it's 4 (Ctrl-D) we replace the buffer with \q<lf> which then quits, even if there's something in the buffer. So simply sending "Ctrl-D to quit" would always be true. Everything else just gets passed through to readline directly. Would need additional work to make the same thing work when readline is disabled. I decided it wouldn't be worth the effort if the basic idea of always intercepting Ctrl-D doesn't gain traction. It's patched against 9.5.1, purely because that's the version I already had source built for on my devbox. Again, if the idea is one that people like I'm happy to rebase it against head. I've also no idea whether Ctrl-D would be 4 in other locales. I also don't know how much of the boilerplate code from the readline docs is required, eg the sigwinch stuff. Geoff
Attachment
On Mon, Jan 15, 2018 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Right, but if we're willing to look at the parse state, we don't need > to cram all possible knowledge into one 80-character string. I'm > thinking about just responding to the current situation, say > > You have begun a quoted string. To end it, type ' > > (or ", or $foo$ as appropriate). I'm inclined to violate our usual > message style guidelines here by not putting any quotes or punctuation > around the ending quote ... more likely to confuse than help. > > Or, if you're not in a string but there's text in the buffer, > > You have entered an incomplete SQL command. > Type ; to send it or \r to discard it. > > Or, if there's no text in the buffer, we print the existing help > message for "help", or just exit for quit/exit. This gets a little complex; you need to note only the parser state but also, in the case of dollar-quoting, what appeared between the two dollar signs when the dollar quotes were opened. Plus, it's quite possible that there are multiple levels of quoting open; I'm not sure I want to print a message like: You have begun a quoted string, To end it, type $$too$$'$$complicated$$ The other problem with this sort of thing is that it gives the user no hint as to why the message got generated. The messages in the patch I sent before were: Use \? for help or press control-C to clear the input buffer. Use \q to quit or press control-C to clear the input buffer. If the user does a cut-and-paste of a bunch of text and gets one of those messages, it doesn't explicitly spell out what triggered the message, but it hints at it. With your proposed message, someone might reply "I know I have begun a quoted string. Why are you telling me about it?". I also think that pressing control-C to clear the input buffer, rather than trying to close out the quotes or the SQL command, is likely to be what most people want to do in this situation. Generally, by the time you resort to typing "quit" or "help" into a program and hoping something good happens, it's a good bet that whatever came before that point wasn't anything great. But I don't know what to do about the revelation that my trusty standby control-C isn't universally the right thing either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Jan 16, 2018 at 6:44 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: > A quick PoC. > > I should say upfront that I've no axe to grind over this, if no-one > likes the idea I don't mind: I'm not sure I like it myself (it's quite > an aggressive stance to take, I think) - I just wanted to see if it > would work, and provide it as a working possibility. > > Basically, I intercept every keypress before we send it to readline. > If it's 4 (Ctrl-D) we replace the buffer with \q<lf> which then quits, > even if there's something in the buffer. So simply sending "Ctrl-D to > quit" would always be true. Everything else just gets passed through > to readline directly. This is an impressive attempt to make it possible to write a short and universally correct help text, but (1) I doubt that we want to override the user's terminal settings and (2) it won't work on non-readline builds. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> This gets a little complex; you need to note only the parser state but
> also, in the case of dollar-quoting, what appeared between the two
> dollar signs when the dollar quotes were opened.
True; perhaps we could cheat and just print $$ in that case.
> Plus, it's quite
> possible that there are multiple levels of quoting open;
No, I don't think so. As far as the command parser is concerned, only the
outermost level has any significance.
> The other problem with this sort of thing is that it gives the user no
> hint as to why the message got generated.
Well, it's answering a "help" or "quit" message. You could extend the
text a bit further, like
You cannot enter a command here because you have an incomplete quoted
string. To end the string, type <whatever>
but it's not going to be quite as short.
> The messages in the patch I sent before were:
> Use \? for help or press control-C to clear the input buffer.
> Use \q to quit or press control-C to clear the input buffer.
Seems to me those are not really any better in terms of
"why was this generated?". Nor is it obvious why clearing the
input buffer is relevant to the user's problem. If they were
thinking in those terms, they'd probably not need an extra clue.
> I also think that pressing control-C to clear the input buffer, rather
> than trying to close out the quotes or the SQL command, is likely to
> be what most people want to do in this situation. Generally, by the
> time you resort to typing "quit" or "help" into a program and hoping
> something good happens, it's a good bet that whatever came before that
> point wasn't anything great. But I don't know what to do about the
> revelation that my trusty standby control-C isn't universally the
> right thing either.
Well, as I said, we could look up the SIGINT character with not that
much extra code, on Unix. Don't know about Windows.
ISTM there are two components to what we need to say here: first,
we have to get the user thinking in the right terms (like "I need
to clear the input buffer") and then we need to instruct them what
to type to accomplish that. Trying to jump directly to the second
part isn't going to fix the problem for novices.
Also, I remain of the opinion that we needn't necessarily teach them the
minimum-keystrokes solution; it's better to teach something that will work
every time. Maybe ^C is close enough on that score, but I'm not sure.
regards, tom lane
Tom Lane wrote: > Also, I remain of the opinion that we needn't necessarily teach them the > minimum-keystrokes solution; it's better to teach something that will work > every time. Maybe ^C is close enough on that score, but I'm not sure. IMO in the spirit of keeping things simple, it's enough to tell people to ^C their way out (and why); anything more complicated than that, such as closing any open quotes, is not catering for the newbie community that this feature is supposed to help. As Robert said, if you're trying to exit the terminal, you don't care too much about any string literals you have open. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 16 January 2018 at 17:20, Robert Haas <robertmhaas@gmail.com> wrote: > (1) I doubt that we want to > override the user's terminal settings and (2) it won't work on > non-readline builds. I'm inclined to agree with (1). (2) is something that could be worked around with (relatively) small effort, and in theory we could grab the value for eof from the terminal. Having said all that, has anyone suggested grabbing and writing out using the "stty quit" value? That appears to work whatever level you're at, readline-or-not, mid-line or not. It wasn't even something I was aware of. Here my quit value is ^\ (Ctrl-backslash) ~ stty -a | grep quit | sed -e 's/.*quit = \([^;]*\).*/\1/' ^\ ~ psql -U postgres psql (9.5.1) Type "help" for help. postgres=# select ' postgres'# ^\Quit ~ psql -U postgres psql (9.5.1) Type "help" for help. postgres=# select $$ postgres$# ^\Quit ~ psql --no-readline -U postgres psql (9.5.1) Type "help" for help. postgres=# select 'Quit Geoff
On 01/17/18 06:50, Geoff Winkless wrote: > Having said all that, has anyone suggested grabbing and writing out > using the "stty quit" value? That appears to work whatever level > you're at, readline-or-not, mid-line or not. It wasn't even something > I was aware of. Well, the usual use of SIGQUIT is to abort a process while generating a core dump so it can be post-mortem debugged, and the abort is immediate without any exit hooks in the process having a chance to execute, so maybe it isn't a habit we would want to inculcate for general use. -Chap
On 17 January 2018 at 14:17, Chapman Flack <chap@anastigmatix.net> wrote: > Well, the usual use of SIGQUIT is to abort a process while generating > a core dump so it can be post-mortem debugged, and the abort is immediate > without any exit hooks in the process having a chance to execute, so > maybe it isn't a habit we would want to inculcate for general use. Ooooh ok :) *facepalm* Geoff
Chapman Flack <chap@anastigmatix.net> writes:
> On 01/17/18 06:50, Geoff Winkless wrote:
>> Having said all that, has anyone suggested grabbing and writing out
>> using the "stty quit" value? That appears to work whatever level
>> you're at, readline-or-not, mid-line or not. It wasn't even something
>> I was aware of.
> Well, the usual use of SIGQUIT is to abort a process while generating
> a core dump so it can be post-mortem debugged, and the abort is immediate
> without any exit hooks in the process having a chance to execute, so
> maybe it isn't a habit we would want to inculcate for general use.
In addition to that, there almost certainly isn't a Windows equivalent.
(I'm still not very sure which of ^C and ^D have Windows equivalents.)
regards, tom lane
On 17 January 2018 at 14:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: > (I'm still not very sure which of ^C and ^D have Windows equivalents.) Ctrl-C quits immediately for me no matter what input stage I'm at in Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and only at beginning-of-line, so I'd say suggesting the user uses Ctrl-C in windows makes sense. ^D doesn't appear to be a special character at all. Geoff
On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote: > On 17 January 2018 at 14:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> (I'm still not very sure which of ^C and ^D have Windows equivalents.) > > Ctrl-C quits immediately for me no matter what input stage I'm at in > Windows' psql. Does it kill the whole program, or just clear the input buffer? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 17 Jan 2018 20:12, "Robert Haas" <robertmhaas@gmail.com> wrote:
On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless <pgsqladmin@geoff.dj> wrote:Does it kill the whole program, or just clear the input buffer?
> On 17 January 2018 at 14:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (I'm still not very sure which of ^C and ^D have Windows equivalents.)
>
> Ctrl-C quits immediately for me no matter what input stage I'm at in
> Windows' psql.
On Windows? It quits completely for me.
Geoff
On 17 January 2018 at 15:00, I wrote:
> Ctrl-C quits immediately for me no matter what input stage I'm at in
> Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and
> only at beginning-of-line, so I'd say suggesting the user uses Ctrl-C
> in windows makes sense. ^D doesn't appear to be a special character at
> all.
My suggestion would be that, since the user has just typed exit<CR> or quit<CR> then writing (on *nix) "Press [[EOFKEY]] on a blank input line to exit" (where [[EOFKEY]] is taken from tcgetattr()'s VEOF value) is sufficient, because the user will already have a blank line in front of them so the immediate instruction ("Press Ctrl-D") will work and if they bother to read further they will remember the further instruction for next time; the simpler "Press Ctrl-C to exit" should be sufficient for Windows.
> Ctrl-C quits immediately for me no matter what input stage I'm at in
> Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and
> only at beginning-of-line, so I'd say suggesting the user uses Ctrl-C
> in windows makes sense. ^D doesn't appear to be a special character at
> all.
My suggestion would be that, since the user has just typed exit<CR> or quit<CR> then writing (on *nix) "Press [[EOFKEY]] on a blank input line to exit" (where [[EOFKEY]] is taken from tcgetattr()'s VEOF value) is sufficient, because the user will already have a blank line in front of them so the immediate instruction ("Press Ctrl-D") will work and if they bother to read further they will remember the further instruction for next time; the simpler "Press Ctrl-C to exit" should be sufficient for Windows.
Geoff
Hi, > It's not really that complicated. Here's a patch. This follows what > Tom suggested in http://postgr.es/m/30157.1513058300@sss.pgh.pa.us and > what I suggested in > https://www.postgresql.org/message-id/CA%2BTgmoZswp00PtcgPfQ9zbbh7HUTgsLLJ9Z1x9E2s8Y7ep048g%40mail.gmail.com > > I've discovered one thing about this design that is not so good, which > is that if you open a single, double, or dollar quote, then the > instructions that are provided under that design do not work: > > rhaas=# select $$ > rhaas$# quit > Use \q to quit or press control-C to clear the input buffer. > rhaas$# \q > rhaas$# well this sucks > rhaas$# > > Obviously this leaves something to be desired, but I think it's > probably just a matter of rephrasing the hint somehow. I didn't have > a good idea off-hand though, so here's the patch as I have it. I reviewed and checked your patch on master branch, and it seems to work well. Here are the results: test=# create table t (quit integer); CREATE TABLE test=# insert into t values (1); INSERT 0 1 test=# select quit from t; quit ------ 1 (1 row) test=# select test-# quit Use \q to quit or press control-C to clear the input buffer. test-# from t; quit ------ 1 (1 row) test=# select 'quit' from t; ?column? ---------- quit (1 row) test=# select ' test'# quit Use \q to quit or press control-C to clear the input buffer. test'# ' from t; ?column? ---------- + quit + (1 row) test=# select $$quit$$ from t; ?column? ---------- quit (1 row) test=# select $$ test$# quit Use \q to quit or press control-C to clear the input buffer. test$# $$ from t; ?column? ---------- + quit + (1 row) test=# select test-# \q bash-4.2$ (psql ended) test=# select ' test'# \q test'# ' from t; ?column? ---------- + \q + (1 row) test=# select $$ test$# \q test$# $$ from t; ?column? ---------- + \q + (1 row) I tried the same test using some commands such as 'exit', 'help' or '\h', and this patch worked well too. Then this patch passed the 'make check' regression tests too. So I think it can be committed. But if you want to modify this patch, I'll check it again. Thanks. Ryoji.
On 01/24/2018 10:17 AM, KAWAMICHI Ryoji wrote: > test=# select ' > test'# quit > Use \q to quit or press control-C to clear the input buffer. > test'# ' from t; > ?column? > ---------- > + > quit + > > (1 row) > test=# select ' > test'# \q > test'# ' from t; > ?column? > ---------- > + > \q + > > (1 row) I haven't applied the patch, but what happens if you combine these? From your examples, I would imagine something like this: test=# select ' test'# quit Use \q to quit or press control-C to clear the input buffer. test'# \q test'# Surely that's not helpful. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Vik Fearing wrote:
> I haven't applied the patch, but what happens if you combine these?
> From your examples, I would imagine something like this:
>
> test=# select '
> test'# quit
> Use \q to quit or press control-C to clear the input buffer.
> test'# \q
> test'#
>
> Surely that's not helpful.
But there's a simple solution to that: make it two messages, one when
inside quotes ("Use Control-C to clear the input buffer, then \q to
quit") and one outside (current wording). Wasn't this already proposed
elsewhere in the thread?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 24 January 2018 at 13:58, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> But there's a simple solution to that: make it two messages, one when
> inside quotes ("Use Control-C to clear the input buffer, then \q to
> quit") and one outside (current wording). Wasn't this already proposed
> elsewhere in the thread?
I don't mean to harp on, but I haven't seen a reason why writing "Use
Ctrl-D on an empty line to quit" (with just "Use Ctrl-C to quit" on
Windows) is any worse than this. Certainly writing "Control-C to clear
the input buffer" on Windows is utlimately confusing, given that it
will actually quit immediately.
Geoff
On Mon, Jan 15, 2018 at 11:10:44AM -0500, Robert Haas wrote: > On Mon, Jan 15, 2018 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> I've discovered one thing about this design that is not so good, which > >> is that if you open a single, double, or dollar quote, then the > >> instructions that are provided under that design do not work: > > > > I was kind of imagining that we could make the hint text vary depending > > on the parsing state. Maybe that's too hard to get to --- but if the > > prompt-creating code knows what it is, perhaps this can too. > > prompt_status does seem to be available in psql's MainLoop(), so I > think that could be done, but the problem is that I don't know exactly > what message would be useful to print when we're in a "in quotes" > state. If I had a good message text for that state, I might just > choose to use it always rather than multiplying the number of > messages. > > More broadly, I think what is needed here is less C-fu than > English-fu. If we come up with something good, we can make it print > that thing. I just read this thread and have some ideas. First, the reason 'help' was added so easily is because it pointed users at getting more information, and it required to be the first command in the query buffer. I realize we are now considering allowing 'help', 'quit', and 'exit' to appear alone on a line with whitespace before it, and remove the requirement that it be the first thing in the query buffer. I think there are a few things to consider. First, allowing whitespace to be before the keyword --- do we really think that typing <space>exit will more likely be typed by a user trying to exit than part of an SQL query? I think requiring no space around the keyword would reduce the number of false hints. Second, I am thinking we can check prompt_status and report "Use \q" if we are not in a quoted string, and suggest "Use Control-D then \q" (or "Use Control-C then \q" on Windows) and be done with it. By printing the Control-D only when we are in a quoted strong, we minimize the number of times that we are wrong due to stty changes. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Thu, Jan 25, 2018 at 03:46:30PM -0500, Bruce Momjian wrote:
> On Mon, Jan 15, 2018 at 11:10:44AM -0500, Robert Haas wrote:
> > prompt_status does seem to be available in psql's MainLoop(), so I
> > think that could be done, but the problem is that I don't know exactly
> > what message would be useful to print when we're in a "in quotes"
> > state. If I had a good message text for that state, I might just
> > choose to use it always rather than multiplying the number of
> > messages.
> >
> > More broadly, I think what is needed here is less C-fu than
> > English-fu. If we come up with something good, we can make it print
> > that thing.
>
> I just read this thread and have some ideas. First, the reason 'help'
> was added so easily is because it pointed users at getting more
> information, and it required to be the first command in the query
> buffer.
>
> I realize we are now considering allowing 'help', 'quit', and 'exit' to
> appear alone on a line with whitespace before it, and remove the
> requirement that it be the first thing in the query buffer.
>
> I think there are a few things to consider.
>
> First, allowing whitespace to be before the keyword --- do we really
> think that typing <space>exit will more likely be typed by a user trying
> to exit than part of an SQL query? I think requiring no space around
> the keyword would reduce the number of false hints.
>
> Second, I am thinking we can check prompt_status and report "Use \q" if
> we are not in a quoted string, and suggest "Use Control-D then \q" (or
> "Use Control-C then \q" on Windows) and be done with it. By printing
> the Control-D only when we are in a quoted strong, we minimize the
> number of times that we are wrong due to stty changes.
I used Robert's patch and modified it to match the ideas I had above.
Specifically no white space can be before 'help', 'exit' or 'quit' and
prompt_status is used to adjust the suggestion. Here is the visible
behavior:
test=> exit
(exits)
test=> SELECT
test-> exit
--> Use \q to quit.
test-> \q
test=> SELECT '
test'> exit
--> Use control-D to quit.
test'> \q
test=> SELECT "
test"> exit
--> Use control-D to quit.
test"> \q
test=> SELECT /*
test*> exit
--> Use control-D to quit.
test*> \q
test=> SELECT 'asbs' AS
test-> exit
--> Use \q to quit.
test-> \q
test=> SELECT 'asbs' AS
test-> exit
test-> ;
exit
------
asbs
(1 row)
One open issue is the existing help display is inaccurate on Windows:
Use \\? for help or press control-C to clear the input buffer.
Oh, it clears the input buffer alright, _and_ exits psql. This patch
also removes the control-C mention on Windows.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachment
On Sun, Jan 28, 2018 at 06:35:06PM -0500, Bruce Momjian wrote: > I used Robert's patch and modified it to match the ideas I had above. > Specifically no white space can be before 'help', 'exit' or 'quit' and > prompt_status is used to adjust the suggestion. Here is the visible > behavior: So what do people want done with this patch? Applied? It looks good to me. :-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Bruce Momjian wrote:
> One open issue is the existing help display is inaccurate on Windows:
>
> Use \\? for help or press control-C to clear the input buffer.
! #ifndef WIN32
! puts(_("Use control-D to quit."));
! #else
! puts(_("Use control-C to quit."));
! #endif
But Control-C exiting on Windows is a bug, isn't it?
Shouldn't we try to fix it to behave like in Unix
rather than documenting it?
Also, the fact that Control-D can quit in the middle of a
multiline query without any confirmation is a usability problem, because
you can always fat-finger a Ctrl+key. By comparison, bash doesn't
accept it and emits the same error as if a script was improperly
terminated. Example:
$ cat '
> [Hit Ctrl+D here] bash: unexpected EOF while looking for matching `''
bash: syntax error: unexpected end of file
$
There's also the issue that, in general, communicating different hints
and advice depending on the host operating system is not ideal.
Because people ask "how do I do such and such in psql?",
they do not ask "how do I do such and such in psql in Windows?".
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
On Thu, Feb 1, 2018 at 12:01:37PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > One open issue is the existing help display is inaccurate on Windows:
> >
> > Use \\? for help or press control-C to clear the input buffer.
>
> ! #ifndef WIN32
> ! puts(_("Use control-D to quit."));
> ! #else
> ! puts(_("Use control-C to quit."));
> ! #endif
>
> But Control-C exiting on Windows is a bug, isn't it?
> Shouldn't we try to fix it to behave like in Unix
> rather than documenting it?
>
> Also, the fact that Control-D can quit in the middle of a
> multiline query without any confirmation is a usability problem, because
> you can always fat-finger a Ctrl+key. By comparison, bash doesn't
> accept it and emits the same error as if a script was improperly
> terminated. Example:
>
> $ cat '
> > [Hit Ctrl+D here] bash: unexpected EOF while looking for matching `''
> bash: syntax error: unexpected end of file
> $
>
> There's also the issue that, in general, communicating different hints
> and advice depending on the host operating system is not ideal.
> Because people ask "how do I do such and such in psql?",
> they do not ask "how do I do such and such in psql in Windows?".
Well, the exit/quit API is just for users to get things done quickly,
for typing portability. I don't think it is something that has to have
a consistent API.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Thu, Feb 1, 2018 at 12:01:37PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > One open issue is the existing help display is inaccurate on Windows:
> >
> > Use \\? for help or press control-C to clear the input buffer.
>
> ! #ifndef WIN32
> ! puts(_("Use control-D to quit."));
> ! #else
> ! puts(_("Use control-C to quit."));
> ! #endif
>
> But Control-C exiting on Windows is a bug, isn't it?
> Shouldn't we try to fix it to behave like in Unix
> rather than documenting it?
Uh, don't Windows users expect Control-C to exit? In some ways Unix
folks might think that too. I don't know if we should change it, but
that is beyond the scope of this patch.
> Also, the fact that Control-D can quit in the middle of a
> multiline query without any confirmation is a usability problem, because
> you can always fat-finger a Ctrl+key. By comparison, bash doesn't
> accept it and emits the same error as if a script was improperly
> terminated. Example:
>
> $ cat '
> > [Hit Ctrl+D here] bash: unexpected EOF while looking for matching `''
> bash: syntax error: unexpected end of file
> $
Again, beyond the scope of this patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Wed, Jan 31, 2018 at 05:51:51PM -0500, Bruce Momjian wrote: > On Sun, Jan 28, 2018 at 06:35:06PM -0500, Bruce Momjian wrote: > > I used Robert's patch and modified it to match the ideas I had above. > > Specifically no white space can be before 'help', 'exit' or 'quit' and > > prompt_status is used to adjust the suggestion. Here is the visible > > behavior: > > So what do people want done with this patch? Applied? It looks good to > me. :-) Patch applied to head. :-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Thu, Feb 1, 2018 at 12:01:37PM +0100, Daniel Verite wrote:
> Also, the fact that Control-D can quit in the middle of a
> multiline query without any confirmation is a usability problem, because
> you can always fat-finger a Ctrl+key. By comparison, bash doesn't
> accept it and emits the same error as if a script was improperly
> terminated. Example:
>
> $ cat '
> > [Hit Ctrl+D here] bash: unexpected EOF while looking for matching `''
> bash: syntax error: unexpected end of file
> $
I just researched this. In bash, it seems Ctrl+C and Ctrl+D do kind of
the same thing, i.e. exit command:
$ echo '
> bash: unexpected EOF while looking for matching `''
bash: syntax error: unexpected end of file
$ echo '
> ^C
$
so the question is whether it is wise that we have ^C and ^D do
different things on psql, or they should do the same thing. I doubt we
would want to change ^D, so it would be changing ^C to exit, except we
use ^C to cancel a query and return you to a prompt, so I don't see how
we can change that either.
In summary, we are probably can't improve this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Bruce Momjian wrote: > > Also, the fact that Control-D can quit in the middle of a > > multiline query without any confirmation is a usability problem, because > > you can always fat-finger a Ctrl+key. By comparison, bash doesn't > > accept it and emits the same error as if a script was improperly > > terminated. Example: > > > > $ cat ' > > > [Hit Ctrl+D here] bash: unexpected EOF while looking for matching `'' > > bash: syntax error: unexpected end of file > > $ BTW, I've missed that Ctrl+D behavior also depends on IGNOREEOF. From https://www.postgresql.org/docs/current/static/app-psql.html IGNOREEOF If set to 1 or less, sending an EOF character (usually Control+D) to an interactive session of psql will terminate the application. If set to a larger numeric value, that many consecutive EOF characters must be typed to make an interactive session terminate. If the variable is set to a non-numeric value, it is interpreted as 10. The default is 0. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
On Thu, Feb 1, 2018 at 07:47:14AM -0500, Bruce Momjian wrote:
> > There's also the issue that, in general, communicating different hints
> > and advice depending on the host operating system is not ideal.
> > Because people ask "how do I do such and such in psql?",
> > they do not ask "how do I do such and such in psql in Windows?".
>
> Well, the exit/quit API is just for users to get things done quickly,
> for typing portability. I don't think it is something that has to have
> a consistent API.
I think the next big question is if/where we want to document this new
behavior. We don't mention 'help' in the psql manual page, but we do
display it in the startup banner:
$ psql test
psql (11devel)
--> Type "help" for help.
What do we want to do with 'exit' and 'quit'? Just leave them
undocumented as compatibility commands? If so, I should at least add a
C comment about this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
I just thought of an inconsistency. First, we now consistently exit with
'exit', 'quit', and '\q' if used in an empty psql query buffer. Also, we now
hint when 'exit' and 'quit' are used in non-empty query buffers:
test=> SELECT
test-> exit
--> Use \q to quit.
We obviously don't need to hint for '\q' since it works in this context.
Where it is odd is that we hint for 'exit' and 'quit' in places that
'\q' doesn't work, but we don't hint for '\q' in the same contexts.
Here is the hint for 'exit' and 'quit':
test=> SELECT '
test'> exit
--> Use control-D to quit.
but we don't hint for '\q':
test=> SELECT '
test'> \q
--> test'>
Should we give the same "Use control-D to quit." hint here for '\q'?
I think it is logical that we should.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On Fri, Feb 2, 2018 at 12:39:28AM -0500, Bruce Momjian wrote: > I just thought of an inconsistency. First, we now consistently exit with > 'exit', 'quit', and '\q' if used in an empty psql query buffer. Also, we now > hint when 'exit' and 'quit' are used in non-empty query buffers: > > test=> SELECT > test-> exit > --> Use \q to quit. > > We obviously don't need to hint for '\q' since it works in this context. > > Where it is odd is that we hint for 'exit' and 'quit' in places that > '\q' doesn't work, but we don't hint for '\q' in the same contexts. > Here is the hint for 'exit' and 'quit': > > test=> SELECT ' > test'> exit > --> Use control-D to quit. > > but we don't hint for '\q': > > test=> SELECT ' > test'> \q > --> test'> > > Should we give the same "Use control-D to quit." hint here for '\q'? > I think it is logical that we should. I have applied the attached patch giving a ^D/^C hint where \q is ignored, and add C comment documenting why exit/quit is not documented. I consider this issue closed, or quited, or exited. :-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Attachment
On Mon, Feb 12, 2018 at 01:28:53AM -0500, Bruce Momjian wrote: > > Should we give the same "Use control-D to quit." hint here for '\q'? > > I think it is logical that we should. > > I have applied the attached patch giving a ^D/^C hint where \q is > ignored, and add C comment documenting why exit/quit is not documented. > > I consider this issue closed, or quited, or exited. :-) FYI, Ivan Panchenko got applause at PGConf.Russia 2018 in Moscow when he mentioned we added quit/exit to psql. :-) I also think the ^D/^C hint for \q when you are in quotes will help too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Wed, Feb 14, 2018 at 12:56:48AM -0500, Bruce Momjian wrote: > On Mon, Feb 12, 2018 at 01:28:53AM -0500, Bruce Momjian wrote: > > > Should we give the same "Use control-D to quit." hint here for '\q'? > > > I think it is logical that we should. > > > > I have applied the attached patch giving a ^D/^C hint where \q is > > ignored, and add C comment documenting why exit/quit is not documented. > > > > I consider this issue closed, or quited, or exited. :-) > > FYI, Ivan Panchenko got applause at PGConf.Russia 2018 in Moscow when he > mentioned we added quit/exit to psql. :-) I also think the ^D/^C hint > for \q when you are in quotes will help too. :) Will there be a video or a reference to the talk slides? I'd love to hear the audience reaction. -- Michael
Attachment
On Wed, Feb 14, 2018 at 03:07:46PM +0900, Michael Paquier wrote:
> On Wed, Feb 14, 2018 at 12:56:48AM -0500, Bruce Momjian wrote:
> > On Mon, Feb 12, 2018 at 01:28:53AM -0500, Bruce Momjian wrote:
> > > > Should we give the same "Use control-D to quit." hint here for '\q'?
> > > > I think it is logical that we should.
> > >
> > > I have applied the attached patch giving a ^D/^C hint where \q is
> > > ignored, and add C comment documenting why exit/quit is not documented.
> > >
> > > I consider this issue closed, or quited, or exited. :-)
> >
> > FYI, Ivan Panchenko got applause at PGConf.Russia 2018 in Moscow when he
> > mentioned we added quit/exit to psql. :-) I also think the ^D/^C hint
> > for \q when you are in quotes will help too.
>
> :)
> Will there be a video or a reference to the talk slides? I'd love to
> hear the audience reaction.
Uh, I think it was this talk, "What to expect in Pg 11 ?"
https://pgconf.ru/en/2018/110916
I know that Ivan Panchenko was not mentioned as a presenter for that,
but he was a presenter. I also know there was a video camera but I
don't see the recordings online. The applause did surprise me.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
14.02.2018 09:17, Bruce Momjian пишет: > On Wed, Feb 14, 2018 at 03:07:46PM +0900, Michael Paquier wrote: >> On Wed, Feb 14, 2018 at 12:56:48AM -0500, Bruce Momjian wrote: >>> On Mon, Feb 12, 2018 at 01:28:53AM -0500, Bruce Momjian wrote: >>>>> Should we give the same "Use control-D to quit." hint here for '\q'? >>>>> I think it is logical that we should. >>>> I have applied the attached patch giving a ^D/^C hint where \q is >>>> ignored, and add C comment documenting why exit/quit is not documented. >>>> >>>> I consider this issue closed, or quited, or exited. :-) >>> FYI, Ivan Panchenko got applause at PGConf.Russia 2018 in Moscow when he >>> mentioned we added quit/exit to psql. :-) I also think the ^D/^C hint >>> for \q when you are in quotes will help too. >> :) >> Will there be a video or a reference to the talk slides? I'd love to >> hear the audience reaction. > Uh, I think it was this talk, "What to expect in Pg 11 ?" > > https://pgconf.ru/en/2018/110916 > > I know that Ivan Panchenko was not mentioned as a presenter for that, > but he was a presenter. I also know there was a video camera but I > don't see the recordings online. The applause did surprise me. This talk was technically divided into two parts, one (Postgres as the Universal DBMS) by Oleg Bartunov, who was late due to the air traffic jam, so it had to be presented by me. Other part (Pg11) was presented by Teodor Sigaev and Alexander Korotkov. The video recordings of the conference will be available on the website in a couple of weeks. >