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
Attachments:
psql-exit-quit.patchapplication/octet-stream; name=psql-exit-quit.patchDownload+12-0
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.
On Fri, Dec 8, 2017 at 7:26 AM, Everaldo Canuto <everaldo.canuto@gmail.com>
wrote:
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 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.
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.
On Fri, Dec 8, 2017 at 8:09 AM, Ryan Murphy <ryanfmurphy@gmail.com> wrote:
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?
regards
Szymon Lipiński
On Fri, Dec 8, 2017 at 8:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"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 likepostgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exitwith 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>:
Show quoted text
"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 concessionto
the word "help" in order to get the reader unfamiliar with our backslash
prefix a non-backslash way to obtain that knowledge apart from readingour
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 likepostgres=> select 2+2 (user forgets semicolon)
postgres-> help
postgres-> quit
postgres-> exitwith 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