public inbox for [email protected]  

help / color / mirror / Atom feed

From: Corey Huinker <[email protected]>
To: Pavel Stehule <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: proposal: psql: psql variable BACKEND_PID
Date: Sun, 5 Feb 2023 18:25:02 -0500
Message-ID: <CADkLM=fBDA6756v8G==tz_fTYHTcjYe6fycr-cf__PGit4mQKg@mail.gmail.com> (raw)
In-Reply-To: <CAFj8pRBQh1y_o8fbA_4zH6PX2uBHr+F7-PaUmbPOna9J1cE9JA@mail.gmail.com>
References: <CAFj8pRBaSVj-8yXcMwKaF7ABx1kYSyUHRM4BdLxoQwf0+RfGsw@mail.gmail.com>
	<CADkLM=fQUAGG2WXO3_2Qci+-nR3URmzi0E03Wvizwg71MORwvg@mail.gmail.com>
	<CAFj8pRDuKBApsSJrF6fNHBHd-b8+78b=Y5Ay4WjxRm2fiw9RdA@mail.gmail.com>
	<CADkLM=d2NXhWeGkQnksAiabuxM4m6q9oM6JMM8NTs6hB=h=9+w@mail.gmail.com>
	<CAFj8pRBQh1y_o8fbA_4zH6PX2uBHr+F7-PaUmbPOna9J1cE9JA@mail.gmail.com>

>
>
>>
>> Clearly, it is hard to write a regression test for an externally volatile
>> value. `SELECT sign(:BACKEND_PID)` would technically do the job, if we're
>> striving for completeness.
>>
>
> I did simple test - :BACKEND_PID should be equal pg_backend_pid()
>
>

Even better.


>
>>
>> Do we want to change %p to pull from this variable and save the
>> snprintf()? Not a measurable savings, more or a don't-repeat-yourself thing.
>>
>
> I checked the code, and I don't think so. Current state is safer (I
> think). The psql's variables are not protected, and I think, so is safer,
> better to
> read the value for prompt directly by usage of the libpq API instead read
> the possibly "customized" variable. I see possible inconsistency,
> but again, the same inconsistency can be for variables USER and DBNAME
> too, and I am not able to say what is significantly better. Just prompt
> shows
> real value, and the related variable is +/- copy in connection time.
>
> I am not 100% sure in this area what is better, but the change requires
> wider and more general discussion, and I don't think the benefits of
> possible
> change are enough. There are just two possible solutions - we can protect
> some psql's variables (and it can do some compatibility issues), or we
> need to accept, so the value in prompt can be fake. It is better to not
> touch it :-).
>

I agree it is out of scope of this patch, but I like the idea of protected
psql variables, and I doubt users are intentionally re-using these vars to
any positive effect. The more likely case is that newer psql vars just
happen to use the names chosen by somebody's script in the past.


>
> done
>
>
>
Everything passes. Docs look good. Test looks good.

view thread (3+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: proposal: psql: psql variable BACKEND_PID
  In-Reply-To: <CADkLM=fBDA6756v8G==tz_fTYHTcjYe6fycr-cf__PGit4mQKg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox