From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: proposal: alternative psql commands quit and exit |
Date: | 2017-12-11 21:38:17 |
Message-ID: | d43d2924-6db1-55cd-c189-081a1cbaaeb4@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/11/2017 04:16 PM, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> No opinion on that, but if the problem is that people don't know how to
>> quit psql, then we should just put that information back into the
>> welcome message and be done with it.
>
> I don't think people read the welcome message, or at least they
> immediately forget it.
I'm still a wholehearted supporter of Robert's idea in
to simply produce helpful messages to stderr when isatty(stdin) and
'exit' or 'quit' arrives on a line by itself. Simple, clear, you end
up learning how psql works, and getting help doing it, at the moment
you want it. No change to semantics. Brilliant.
I'm not just saying that because its exactly the suggestion I was
preparing to compose when I scrolled to Robert's message and saw
I'd been scooped. (Or maybe I am.)
I don't even think it's necessarily worthwhile to treat them any
differently when *not* on a continuation line. Why not just always
have a bare 'exit' or 'quit', when isatty(stdin), give you a little
reminder about \?, \q, ^C/\r and leave the next step up to you?
Maybe the part of the reminder about ^C / \r to clear the input
buffer could be reserved for when the buffer isn't empty. On second
thought, no, it will be appropriate every time, because now the buffer
has at least your exit or quit in it.
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-12-11 21:39:08 | Re: Jsonb transform for pl/python |
Previous Message | Andres Freund | 2017-12-11 21:32:31 | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |