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