Обсуждение: BUG #14916: psql \r is invalid in PostgreSQL 10

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

BUG #14916: psql \r is invalid in PostgreSQL 10

От
xyh@nvn.xyz
Дата:
The following bug has been logged on the website:

Bug reference:      14916
Logged by:          Yunhe Xu
Email address:      xyh@nvn.xyz
PostgreSQL version: 10.1
Operating system:   Red Hat Enterprise Linux Server release 6.7
Description:

Hello,
In PostgreSQL 10.0 and 10.1 .
psql \r is invalid.

postgres=# select count(*) from abc;
 count 
-------
     0
(1 row)

postgres=# \r
Query buffer reset (cleared).
postgres=# \p
select count(*) from abc;

In 9.4.14,don't have this problem.
postgres=# select count(*) from abc;
 count 
-------
     0
(1 row)

postgres=# \r
Query buffer reset (cleared).
postgres=# \p
Query buffer is empty.

Kind regards.
Yunhe



Re: BUG #14916: psql \r is invalid in PostgreSQL 10

От
Tom Lane
Дата:
xyh@nvn.xyz writes:
> Hello,
> In PostgreSQL 10.0 and 10.1 .
> psql \r is invalid.

Please say why you think this is "invalid".  I'm pretty sure
it was an intentional behavioral change (associated with the
rewrite to support \if).  In any case it's not obviously worse
than before.  \r is supposed to clear the current query input
string; it says nothing about deleting history.
        regards, tom lane


BUG #14916: psql \r is invalid in PostgreSQL 10

От
"David G. Johnston"
Дата:
On Thursday, November 16, 2017, Tom Lane <tgl@sss.pgh.pa.us> wrote:
xyh@nvn.xyz writes:
> Hello,
> In PostgreSQL 10.0 and 10.1 .
> psql \r is invalid.

Please say why you think this is "invalid".  I'm pretty sure
it was an intentional behavioral change (associated with the
rewrite to support \if).  In any case it's not obviously worse
than before.  \r is supposed to clear the current query input
string; it says nothing about deleting history.


Actually, \r is behaving the same.  The behavior of \p has been changed (at least per the docs) to print the last executed query if the current buffer is empty.  This behavior change doesn't seem to be in the release notes.

David J.

Re: BUG #14916: psql \r is invalid in PostgreSQL 10

От
Tom Lane
Дата:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thursday, November 16, 2017, Tom Lane <tgl@sss.pgh.pa.us
> <javascript:_e(%7B%7D,'cvml','tgl@sss.pgh.pa.us');>> wrote:
>> Please say why you think this is "invalid".  I'm pretty sure
>> it was an intentional behavioral change (associated with the
>> rewrite to support \if).  In any case it's not obviously worse
>> than before.  \r is supposed to clear the current query input
>> string; it says nothing about deleting history.

> Actually, \r is behaving the same.  The behavior of \p has been changed (at
> least per the docs) to print the last executed query if the current buffer
> is empty.  This behavior change doesn't seem to be in the release notes.

No, it's always done that; the docs are just more clear about it now
(cf. commit 68dba97a4).  This works the same in all versions of psql
back to perhaps 7.0:

regression=# select 2+2;?column? 
----------       4
(1 row)

regression=# \p
select 2+2;

and for that matter so does this:

regression=# select 2+2;?column? 
----------       4
(1 row)

regression=# \p
select 2+2;
regression=# select 2+1
regression-# \r
Query buffer reset (cleared).
regression=# \p
select 2+2;
regression=# \g?column? 
----------       4
(1 row)

What's different is that \r used to be willing to clear the previous-query
buffer if the current-query buffer was empty:

regression=# select 2+2;?column? 
----------       4
(1 row)

regression=# \p
select 2+2;
regression=# \r
Query buffer reset (cleared).
regression=# \p
Query buffer is empty.
regression=# \g
regression=# 

That was surprising, undocumented, and (AFAICT) an accidental result of
some weird coding rather than anything the code actually intended to do.
So we changed it:

regression=# select 2+2;?column? 
----------       4
(1 row)

regression=# \r
Query buffer reset (cleared).
regression=# \p
select 2+2;
regression=# \g?column? 
----------       4
(1 row)

There was nothing to document since the docs never explained the old
behavior anyway.  Maybe there should have been a release note entry
about it, but I don't see how such an entry could be much shorter
than what I just wrote, and it didn't seem worth it.
        regards, tom lane