Re: psql: backslash fix - Mailing list pgsql-patches

On Tue, Mar 12, 2002 at 01:53:20PM -0500, Neil Conway wrote:
> On Tue, 2002-03-12 at 13:21, Ross J. Reedstrom wrote:
> > Neil,
> > You don't actually _use_ psql much, do you?
>
> I do use it a fair amount -- but I find the accusatory tone a bit
> unnecessary. I'm trying to improve psql here -- perhaps our views
> differ, but so what? I'm willing to be convinced...

Sorry about that - I needed lunch, and my brain gets a bit wonky sometimes
when it's short of glucose. I think it was the isuggestion of losing
functionality "for consistency's sake" (or equivalant verbage) that
touched a nerve for me.

>
> > Yes, it's a different mode of
> > operation than a straight interpreter. That's actually a good thing. The
> > change you've suggested 'for consistencies sake' strike me as making
> > psql a lot more difficult to use, in particular, clearing the buffer
> > on error. One of the big differences is that multiline input is handled
> > differently - if you've got a long buffer, it's in multiple lines. Perhaps
> > that should be changed to more like bash's handling of multiline input,
> > bug throwing it away is wrong.
>
> Well sure, don't clear the buffer on error -- recall the last line of
> input and put the cursor where the error occured. That's another one of
> the suggestions I made, and I think it satisfies your concerns. Peter
> said he'd look into implementing it.
>

Agreed. Much better. Although, as I mention above, long expression handling
is less than perfect, in any case: having to 'up arrow' for each line in a
multi-line command is wonky. Bash actually handles this pretty well: all
the lines of a multiline command are available asa single history item.
Although, displaying and editing such history items are the best way to find
out what's broken in your current terminfo entry.

> Regardless, I do think the current behavior should be improved. In the
> case I ran into (a simple SQL statement with a malformed backslash
> command) psql behaves in an extremely unintuitive fashion: the previous
> buffer is silently prepended to the current one, and the only indication
> of this is that the prompt changes to a "->".

That's pretty standard shell commandline multiline practice: the 'secondary
prompt' shows up for an incomplete command.

>
> Whether this is improved by clearing the buffer (and thus returning to
> "=>"), or by recalling the previous buffer and printing it to the screen
> (allowing the user to continue editing it), I don't really mind.

If the entire previous command were just an uparrow away, I'd even agree
to resetting the current buffer. Otherwise, reprinting the current line's
worth, as you suggest, might be a good choice.

Ross