Re: BUG #15002: Unexpected behaviour in psql \r command - Mailing list pgsql-bugs

From Petr Korobeinikov
Subject Re: BUG #15002: Unexpected behaviour in psql \r command
Date
Msg-id CAJL5ff9eJBc2dG5W31X5UpDHu-UOo3+kE4w7YymtWGiT4RHLMQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15002: Unexpected behaviour in psql \r command  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
In this case \r subcommand seems to be completely useless.
It does absolutely nothing.

2018-01-09 20:58 GMT+03:00 David G. Johnston <david.g.johnston@gmail.com>:
On Tue, Jan 9, 2018 at 10:45 AM, PG Bug reporting form <noreply@postgresql.org> wrote:
Previously (at least in 9.6) previous_buf hasn’t been used for any kinds of
\e subcommand.
Now if query_buf is empty previous buffer contents is used.

​IIUC the complaint is that it is no longer possible to use \edit​ to generate a completely empty temporary query that can then be written from scratch.

The v10 behavior is desirable so that leaves either learning a new idiom to accomplish your goal or adding something like "\edit -" to explicitly invoke the desired behavior.

Doing:

# SELECT <enter>
# \edit

Seems reasonably straight forward to get a editor for a newly query instead of the previous one.

David J.


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15003: pg_terminate_backend does not work
Next
From: PG Bug reporting form
Date:
Subject: BUG #15004: Missing libprotobuf-c in pgdg-centos10-10-2.noarch.rpm