+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.
