Re: Suggested fix for \p and \r in psql - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Suggested fix for \p and \r in psql
Date
Msg-id alpine.DEB.2.20.1704021645010.4632@lancre
Whole thread Raw
List pgsql-hackers
Hello Daniel,

> I've noticed two issues with the query buffer post-commit e984ef5
> (Support \if ... \elif ... \else ... \endif in psql scripting):

I thought that Tom's changes were somehow intentional, in order to 
simplify the code.

> 1. \p ignores the "previous buffer". Example:
>
> postgres=# select 1;
> ?column?
> ----------
>     1
> (1 row)
>
> postgres=# \p
> Query buffer is empty.

Yep. Note that it still works with:
  SELECT 1 \g

> That doesn't match the pre-commit behavior, and is not
> consistent with \e or \w

Indeed, there is definitely an issue because \g executes something where 
\p prints nothing...
  10devel> SELECT 1; -- 1  10devel> \p -- <empty>  10devel> \g -- 1!

> 2. \r keeps the "previous buffer". I think it should clear it. Example:

I'm not that sure, \r clears the current buffer and restores the previous 
one, so that two \r are needed to fully clear:
  9.6> SELECT 1; -- 1  9.6> SELECT 2 \r -- first clear  9.6> \g -- 1 (redo SELECT 1)  9.6> \r -- second clear  9.6> \g
--<nothing>
 


Patch applies, make check ok. However:

I tend to agree that 1 above is a regression, but ISTM that 2 is somehow 
the expected behavior, i.e. \r should not clear the previous buffer, just 
the current one, so that two \r are needed for a "full" clear. \r should 
clear the current buffer and restores the previous one.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Dong Yuan
Date:
Subject: [GSoC] Question about "Explicitly support predicate locks in indexaccess methods besides btree"
Next
From: Tom Lane
Date:
Subject: Re: Performance improvement for joins where outer side is unique