Обсуждение: BUG #16034: `\set ECHO all` doesn't work for \e command
The following bug has been logged on the website:
Bug reference: 16034
Logged by: Pavlo Golub
Email address: pavlo.golub@cybertec.at
PostgreSQL version: 11.5
Operating system: All
Description:
I want command sent to the server with \e command to be echoed to the
terminal. For this:
timetable=# \set ECHO all
timetable=# \e
version
--------------------------------------------------------------------------------------------------------
PostgreSQL 11.2 on x86_64-pc-mingw64, compiled by gcc.exe (Rev5, Built by
MSYS2 project) 4.9.2, 64-bit
(1 row)
timetable=#
Should it print out the query I've entered in the editor? The same situation
for `\set ECHO_HIDDEN on`
PG Bug reporting form <noreply@postgresql.org> writes:
> I want command sent to the server with \e command to be echoed to the
> terminal.
Uh, what? \e doesn't send anything to the server, it just edits
the query buffer locally.
I could interpret your request as being that ECHO_HIDDEN causes "hidden"
commands to be shoved into the command history (whence they could be
recalled and edited) as well as being echoed. While I can see some
use-case for that, I think it'd more usually be an annoyance and/or break
cases that work today. If we decide that's a useful feature, I'd vote
for leaving ECHO_HIDDEN alone and inventing a separate variable to enable
it (HISTORY_HIDDEN, or some such?).
regards, tom lane
On Wed, Oct 2, 2019 at 5:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> PG Bug reporting form <noreply@postgresql.org> writes:
> > I want command sent to the server with \e command to be echoed to the
> > terminal.
>
> Uh, what? \e doesn't send anything to the server, it just edits
> the query buffer locally.
>
According to the manual:
The new contents of the query buffer are then re-parsed according to
the normal rules of psql, treating the whole buffer as a single line.
Any complete queries are immediately executed (sic!); that is, if the
query buffer contains or ends with a semicolon, everything up to that
point is executed.
My terminal looks like this:
timetable=# \e
version
--------------------------------------------------------------------------------------------------------
PostgreSQL 11.2 on x86_64-pc-mingw64, compiled by gcc.exe (Rev5,
Built by MSYS2 project) 4.9.2, 64-bit
(1 row)
As you can see, you have no idea what the query was executed.
And sometimes you really want to know that, especially trying to analyze
query were executed during a session.
Agree, probably ECHO is not the best solution since it's intended not
for interactive mode.
ECHO_HIDDEN seems to be the correct approach.
>
> I could interpret your request as being that ECHO_HIDDEN causes "hidden"
> commands to be shoved into the command history (whence they could be
> recalled and edited) as well as being echoed. While I can see some
> use-case for that, I think it'd more usually be an annoyance and/or break
> cases that work today. If we decide that's a useful feature, I'd vote
> for leaving ECHO_HIDDEN alone and inventing a separate variable to enable
> it (HISTORY_HIDDEN, or some such?).
>
> regards, tom lane
Pavlo Golub <pavlo.golub@cybertec.at> writes:
> On Wed, Oct 2, 2019 at 5:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Uh, what? \e doesn't send anything to the server, it just edits
>> the query buffer locally.
> According to the manual:
> The new contents of the query buffer are then re-parsed according to
> the normal rules of psql, treating the whole buffer as a single line.
> Any complete queries are immediately executed (sic!); that is, if the
> query buffer contains or ends with a semicolon, everything up to that
> point is executed.
Ah. So there are really two separate issues here:
1. If there's complete query(s), they aren't echoed to the terminal
before execution. Probably we could just echo them and be done
(though I wonder if this ought to depend on interactiveness). I'm
not hugely excited about that, but it's reasonable.
2. If there's a partial query, it's stuffed back into the query
buffer but you don't see it. This is definitely bad, and IIRC it's
been complained of before, unlike point 1. The problem is that
there's no portable way (AFAIK) of getting libreadline/libedit to
echo the partial query. If you know of a way, please send a patch.
regards, tom lane
Pavlo Golub wrote: > As you can see, you have no idea what the query was executed. > And sometimes you really want to know that, especially trying to analyze > query were executed during a session. > Agree, probably ECHO is not the best solution since it's intended not > for interactive mode. \set ECHO queries would display them including immediately after \e in an interactive session. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
On Wed, Oct 2, 2019 at 7:47 PM Daniel Verite <daniel@manitou-mail.org> wrote: > > Pavlo Golub wrote: > > > As you can see, you have no idea what the query was executed. > > And sometimes you really want to know that, especially trying to analyze > > query were executed during a session. > > Agree, probably ECHO is not the best solution since it's intended not > > for interactive mode. > > \set ECHO queries > would display them including immediately after \e in an interactive > session. Oh, great! That works! Thanks! But why ECHO all doesn't? Should all include queries by default? > > > Best regards, > -- > Daniel Vérité > PostgreSQL-powered mailer: http://www.manitou-mail.org > Twitter: @DanielVerite
Pavlo Golub wrote: > > \set ECHO queries > > would display them including immediately after \e in an interactive > > session. > > Oh, great! That works! Thanks! But why ECHO all doesn't? Should all > include queries by default? As I understand, "ECHO all" does nothing when the commands are read interactively. So in that mode it's the same as "ECHO none", and it doesn't seem very useful indeed. It appears to be an ancient decision, since it was already described in the 7.1 docs pretty much like it is today: https://www.postgresql.org/docs/7.1/app-psql.html Maybe I'm missing the use case of neutralizing "ECHO all" interactively, but otherwise I agree it would be more intuitive and useful if it did the same thing in interactive and non-interactive modes. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
"Daniel Verite" <daniel@manitou-mail.org> writes: >> Pavlo Golub wrote: >>> \set ECHO queries >>> would display them including immediately after \e in an interactive >>> session. >> Oh, great! That works! Thanks! But why ECHO all doesn't? Should all >> include queries by default? > As I understand, "ECHO all" does nothing when the commands are > read interactively. So in that mode it's the same as "ECHO none", > and it doesn't seem very useful indeed. > It appears to be an ancient decision, since it was already > described in the 7.1 docs pretty much like it is today: > https://www.postgresql.org/docs/7.1/app-psql.html The reason why it doesn't echo commands in interactive mode is that you presumably just typed the command (and had it echoed back at you, by the tty driver if not readline), so echoing it again would be duplicative and annoying. I don't think we should add such annoyance in normal cases as a band-aid for the problem with \e. BTW, "ECHO all" and "ECHO queries" are totally different; the one is not a superset of the other. "all" prints lines as they are read, the other prints commands when they are sent to the server. One reason why you don't want "ECHO all" to be active in interactive mode is that it'd make a complete hash of things while typing a multiline query. regards, tom lane