psql's \r broken since e984ef5861d
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37120psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 05:50 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37120_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37120_1 && git checkout t37120_1Patchset v1 (message #1) is on t37120_1
Hello,
Unless I miss something, \r isn't working anymore, since
exec_command_print() fallback to display previous_buf if query_buf has
been freed.
Trivial patch to fix issue (free both buffers in exec_command_reset())
attached.
Regards.
--
Julien Rouhaud
Julien Rouhaud <julien.rouhaud@dalibo.com> writes:
Unless I miss something, \r isn't working anymore,
Works for me. Please describe exactly what misbehavior you're seeing.
What libreadline or libedit version are you using?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 20/07/2017 03:34, Tom Lane wrote:
Julien Rouhaud <julien.rouhaud@dalibo.com> writes:
Unless I miss something, \r isn't working anymore,
Works for me. Please describe exactly what misbehavior you're seeing.
What libreadline or libedit version are you using?
I have libreadline 7.0_p3.
Here's a simple test case, last \p still show the query buffer:
psql -X postgres
postgres=# select version();
version
--------------------------------------------------------------------------------------------------------------------
PostgreSQL 10beta2@decb08ebdf on x86_64-pc-linux-gnu, compiled by gcc
(Gentoo 4.9.3 p1.5, pie-0.6.4) 4.9.3, 64-bit
(1 row)
postgres=# \p
select version();
postgres=# \r
Query buffer reset (cleared).
postgres=# \p
select version();
On a 9.6:
postgres=# select version();
version
------------------------------------------------------------------------------------------------------------------
PostgreSQL 9.6.3@3c017a545f on x86_64-pc-linux-gnu, compiled by gcc
(Gentoo 4.9.3 p1.5, pie-0.6.4) 4.9.3, 64-bit
(1 row)
postgres=# \p
select version();
postgres=# \r
Query buffer reset (cleared).
postgres=# \p
Query buffer is empty.
--
Julien Rouhaud
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Julien Rouhaud <julien.rouhaud@dalibo.com> writes:
On 20/07/2017 03:34, Tom Lane wrote:
Works for me. Please describe exactly what misbehavior you're seeing.
Here's a simple test case, last \p still show the query buffer:
Ah. I don't feel like trawling the archives for the discussion right now,
but I believe this was an intentional change to make the behavior more
consistent. Prior versions did things weirdly differently depending on
whether you'd typed anything, eg modifying your example slightly:
regression=# select version();
version
----------------------------------------------------------------------------------------------------------
PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit
(1 row)
regression=# \p
select version();
regression=# mistake
regression-# \r
Query buffer reset (cleared).
regression=# \p
select version();
regression=# \g
version
----------------------------------------------------------------------------------------------------------
PostgreSQL 9.6.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit
(1 row)
I think we felt that throwing away the previous-query buffer
when we didn't have to was generally to be avoided, so we
wanted to standardize on this behavior not the other one.
Do you think differently?
I have some recollection that there were also cases where \p
would print something different than what \g would execute,
which of course is quite nasty.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
Ah. I don't feel like trawling the archives for the discussion right now,
but I believe this was an intentional change to make the behavior more
consistent.
Oh ... a quick look in the commit log finds the relevant discussion:
/messages/by-id/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90@manitou-mail.org
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 20/07/2017 04:24, Tom Lane wrote:
I wrote:
Ah. I don't feel like trawling the archives for the discussion right now,
but I believe this was an intentional change to make the behavior more
consistent.Oh ... a quick look in the commit log finds the relevant discussion:
/messages/by-id/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90@manitou-mail.org
Oh I see. Thanks a lot, sorry for the noise.
--
Julien Rouhaud
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers