Re: proposal: psql: psql variable BACKEND_PID

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: proposal: psql: psql variable BACKEND_PID
Date: 2023-02-13 17:06:23
Message-ID: 1568349c-b6d9-2031-0820-904fa8dbeda3@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.02.23 10:11, Pavel Stehule wrote:
> 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.

But what do you need the backend PID for in the first place?

Of course, you might want to use it to find your own session in
pg_stat_activity or something like that, but then you're already in a
query and can use pg_backend_pid(). What do you need the backend PID
for outside of such a query?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-02-13 17:21:57 Re: ERROR: permission info at index 1 ....
Previous Message Tom Lane 2023-02-13 17:01:38 Re: ExecRTCheckPerms() and many prunable partitions (sqlsmith)