Re: proposal: psql: psql variable BACKEND_PID

po 6. 2. 2023 v 0:25 odesílatel Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
napsal:

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

bash variables are not protected too. I know this is in a different
context, and different architecture. It can be a very simple patch, but it
needs wider discussion. Probably it should be immutable, it is safer, and
now I do not have any useful use case for mutability of these variables.

Regards

Pavel

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