psql's \r broken since e984ef5861d
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
Attachments:
fix_psql_r.difftext/x-patch; name=fix_psql_r.diffDownload+4-3
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