From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: proposal: psql: psql variable BACKEND_PID |
Date: | 2023-02-09 09:11:21 |
Message-ID: | CAFj8pRDd70fx0th7s-RdTaBjGybYtz_7oQeHAPNa+RjOLrYn-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
čt 9. 2. 2023 v 9:57 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> napsal:
> On 03.02.23 11:41, Pavel Stehule wrote:
> > We can simply allow an access to backend process id thru psql variable.
> > I propose the name "BACKEND_PID". The advantages of usage are simple
> > accessibility by command \set, and less typing then using function
> > pg_backend_pid, because psql variables are supported by tab complete
> > routine. Implementation is very simple, because we can use the function
> > PQbackendPID.
>
> What would this be useful for?
>
> You can mostly do this using
>
> select pg_backend_pid() AS "BACKEND_PID" \gset
>
there are 2 (3) my motivations
first and main (for me) - I can use psql variables tab complete - just
:B<tab> - it is significantly faster
second - I can see all connection related information by \set
third - there is not hook on reconnect in psql - so if you implement
BACKEND_PID by self, you ensure to run query with pg_backend_pid() after
any reconnect or connection change.
It is clean so you can run "select pg_backend_pid() AS "BACKEND_PID" \gset"
and you can store it to .psqlrc. But most of the time I am in customer's
environment, and I have the time, possibility to do a complete setup of
.psqlrc. It looks (for me) like a generally useful feature to be
everywhere.
Regards
Pavel
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Shinderuk | 2023-02-09 09:14:44 | Re: A bug with ExecCheckPermissions |
Previous Message | Hans Buschmann | 2023-02-09 09:03:32 | AW: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 |