Re: proposal: psql: psql variable BACKEND_PID

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: proposal: psql: psql variable BACKEND_PID
Date: 2023-02-06 14:30:14
Message-ID: CAFj8pRD5ASGgKkH9wXiJF9ZEN5JAt+MAoUypt6byMvUW9gZFGw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 6. 2. 2023 v 13:03 odesílatel Daniel Verite <daniel(at)manitou-mail(dot)org>
napsal:

> I wrote:
>
> > > In the varlistentry, I suggest we add "This variable is unset when the
> > > connection is lost." after "but can be changed or unset.
> >
> > Personally I'd much rather have BACKEND_PID set to 0 rather than being
> unset
> > when not connected. For one thing it allows safely using \if
> :BACKEND_PID.
>
> Oops it turns out that was wishful thinking from me.
> \if does not interpret a non-zero integer as true, except for the
> value "1".
> I'd still prefer BACKEND_PID being 0 when not connected, though.
>

I think psql never tries to execute a query if the engine is not connected,
so for usage in queries undefined state is not important - it will be
always defined.

for using in \if is unset may be a better state, because you can try to use
{? varname} syntax.

0 is theoretically valid process id number, so I am not sure if 0 is ok. I
don't know if some numbers can be used like invalid process id?

>
> Best regards,
> --
> Daniel Vérité
> https://postgresql.verite.pro/
> Twitter: @DanielVerite
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2023-02-06 14:38:34 Re: Pluggable toaster
Previous Message Aleksander Alekseev 2023-02-06 14:03:07 Re: [PATCH] Compression dictionaries for JSONB