Обсуждение: [HACKERS] psql's \r broken since e984ef5861d

Поиск
Список
Период
Сортировка

[HACKERS] psql's \r broken since e984ef5861d

От
Julien Rouhaud
Дата:
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

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

Вложения

Re: [HACKERS] psql's \r broken since e984ef5861d

От
Tom Lane
Дата:
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



Re: [HACKERS] psql's \r broken since e984ef5861d

От
Julien Rouhaud
Дата:
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@decb08ebdfon 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@3c017a545fon 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



Re: [HACKERS] psql's \r broken since e984ef5861d

От
Tom Lane
Дата:
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.3on 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.3on 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



Re: [HACKERS] psql's \r broken since e984ef5861d

От
Tom Lane
Дата:
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:
https://www.postgresql.org/message-id/flat/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90%40manitou-mail.org
        regards, tom lane



Re: [HACKERS] psql's \r broken since e984ef5861d

От
Julien Rouhaud
Дата:
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:
> https://www.postgresql.org/message-id/flat/9b4ea968-753f-4b5f-b46c-d7d3bf7c8f90%40manitou-mail.org
> 

Oh I see.  Thanks a lot, sorry for the noise.

-- 
Julien Rouhaud