From: | Gasper Zejn <zejn(at)owca(dot)info> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: proposal: alternative psql commands quit and exit |
Date: | 2017-12-12 14:35:28 |
Message-ID: | 78c24873-6f05-ddaf-bb53-156c93a7df84@owca.info |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12. 12. 2017 06:58, Tom Lane wrote:
> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
>> I doubt I've ever written just "exit" or "quit" without indentation. I
>> think if it requires them to be a bareword with no indentation, strictly
>> ^(exit|quit)\n when isatty, then that's probably a safe and helpful choice.
> FWIW, I think that the special behavior (whatever it winds up being
> exactly) ought to trigger on an input line matching
>
> [whitespace]*help[whitespace]*(;[whitespace]*)?
>
> and similarly for exit/quit. I think that novices might have internalized
> enough SQL syntax to think that they need to terminate the command with a
> semicolon --- in fact, we regularly see examples in which seasoned users
> think they need to terminate backslash commands with a semicolon, so
> that's hardly far-fetched. And we might as well allow as much whitespace
> as we can, because nobody but Guido Rossum thinks that having whitespace
> be semantically significant is a good idea.
>
> regards, tom lane
>
If tabs are considered whitespace, psql can sometimes treat it as
semantically significant, since
"create materialized<tab>test11 as select 1;" will be autocompleted to
correct syntax if you paste the line into interactive psql session.
I have seen psql error out with invalid syntax when a similar query was
pasted and psql autocompleted it.
kind regards, Gasper
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Finzel | 2017-12-12 14:54:00 | Re: Testing Extension Upgrade Paths |
Previous Message | Robert Haas | 2017-12-12 14:25:24 | Re: Out of date comment in cached_plan_cost |