Re: proposal: alternative psql commands quit and exit

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

In response to

Responses

Browse pgsql-hackers by date

  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