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
>
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 |