# Re: [HACKERS] Suggested fix for \p and \r in psql

```
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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
```