Re: proposal: alternative psql commands quit and exit - Mailing list pgsql-hackers

From Gasper Zejn
Subject Re: proposal: alternative psql commands quit and exit
Date
Msg-id 78c24873-6f05-ddaf-bb53-156c93a7df84@owca.info
Whole thread Raw
In response to Re: proposal: alternative psql commands quit and exit  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal: alternative psql commands quit and exit  (Jeremy Finzel <finzelj@gmail.com>)
List pgsql-hackers
On 12. 12. 2017 06:58, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Out of date comment in cached_plan_cost
Next
From: Jeremy Finzel
Date:
Subject: Re: Testing Extension Upgrade Paths