Re: proposal: alternative psql commands quit and exit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Everaldo Canuto <everaldo(dot)canuto(at)gmail(dot)com>
Subject: Re: proposal: alternative psql commands quit and exit
Date: 2018-01-07 00:58:37
Message-ID: 9673.1515286717@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> I'm not sure what the usual shape of 'consensus' or 'resolution' is in these things,
> but it seems to me that the branch of this email thread that leads here (through the
> message from Robert that I'm replying to) is the one that felt like it was converging.

> I thought it was converging on the idea that

> ^[whitespace]*(quit|exit)[whitespace]*(;[whitespace]*)?$

> would be treated specially when interactive, whether on a first or a continuation line,
> and that the special treatment would be a helpful explanatory message to the
> interactive user, while nevertheless appending the text to the query buffer.

That's what I thought, too. I also think that we should recognize "help"
under exactly the same circumstances --- right now only a subset of what
you specify here will trigger the help response.

> One possibly not-yet-converged point was whether the special treatment should
> be the same on a first line, or should just actually quit in that case.

I can get on board with actually quitting if it's on the first line,
which is equivalent to the current behavior for "help". That is,
all three would do-what-it-says-on-the-tin if entered when the query
buffer is empty, while they'd all emit an explanatory message (maybe
the same for all three, or maybe not) if entered when the query
buffer is not empty.

I doubt we have consensus on just what the explanatory message should
say, but maybe the author can give us a proposal to shoot at.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-01-07 03:00:09 Re: Fix a Oracle-compatible instr function in the documentation
Previous Message Peter Geoghegan 2018-01-07 00:43:44 Re: [HACKERS] GUC for cleanup indexes threshold.