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.