On Fri, Dec 8, 2017 at 2:07 PM, Tom Lane <t...@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
