Re: proposal: psql: psql variable BACKEND_PID

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-13 17:33:33
Message-ID: CAFj8pRAvpM-2mUEqWUzeYr0rYOiWwSHn5vDQpuJf=SXH0fMNxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 13. 2. 2023 v 18:06 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> napsal:

> 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 every real use case you can use pg_backend_pid(), but you need to write
a complete name without tab complete, and you need to know so this function
is available.

BACKEND_PID is supported by tab complete, and it is displayed in \set list
and \? variables. Nothing less, nothing more, Custom psql variable can have
some obsolete value.

I can imagine using :BACKEND_PID in \echo command - and it just saves you
one step with its own custom variable.

It is just some more comfort with almost zero cost.

Regards

Pavel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-02-13 17:39:47 Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?
Previous Message Tom Lane 2023-02-13 17:21:57 Re: ERROR: permission info at index 1 ....