Re: proposal: psql: psql variable BACKEND_PID

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