Re: [HACKERS] psql's \r broken since e984ef5861d - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] psql's \r broken since e984ef5861d
Date
Msg-id 11958.1500516953@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] psql's \r broken since e984ef5861d  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
Responses Re: [HACKERS] psql's \r broken since e984ef5861d
List 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.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise