Re: proposal: alternative psql commands quit and exit

Robert Haas <robertmhaas(at)gmail(dot)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