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

From Tom Lane
Subject Re: proposal: alternative psql commands quit and exit
Date
Msg-id 9673.1515286717@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal: alternative psql commands quit and exit  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
Chapman Flack <chap@anastigmatix.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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] GUC for cleanup indexes threshold.
Next
From: Tom Lane
Date:
Subject: Re: Fix a Oracle-compatible instr function in the documentation