Re: proposal: psql: psql variable BACKEND_PID

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: psql: psql variable BACKEND_PID
Дата
Msg-id CAFj8pRDd70fx0th7s-RdTaBjGybYtz_7oQeHAPNa+RjOLrYn-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: psql: psql variable BACKEND_PID  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: proposal: psql: psql variable BACKEND_PID  (Andres Freund <andres@anarazel.de>)
Re: proposal: psql: psql variable BACKEND_PID  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers


čt 9. 2. 2023 v 9:57 odesílatel Peter Eisentraut <peter.eisentraut@enterprisedb.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hans Buschmann
Дата:
Сообщение: AW: Wrong rows estimations with joins of CTEs slows queries by more than factor 500
Следующее
От: Sergey Shinderuk
Дата:
Сообщение: Re: A bug with ExecCheckPermissions