with doc and unsetting variable
Regards
Pavel
Patch applies.
Manually testing confirms that it works, at least for the connected state. I don't actually know how get psql to invoke DISCONNECT, so I killed the dev server and can confirm
[222281:14:57:01 EST] corey=# \echo :BACKEND_PID
222281
[222281:14:57:04 EST] corey=# select 1;
FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The connection to the server was lost. Attempting reset: Failed.
Time: 1.554 ms
[:15:02:31 EST] !> \echo :BACKEND_PID
: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()
The inability to easily DISCONNECT via psql, and the deleterious effect that would have on other regression tests tells me that we can leave that one untested.
I agree
Notes:
This effectively makes the %p prompt (which I use in the example above) the same as %:BACKEND_PID: and we may want to note that in the documentation.
done
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 :-).
In the varlistentry, I suggest we add "This variable is unset when the connection is lost." after "but can be changed or unset.
done
Regards
Pavel