Re: proposal: psql: psql variable BACKEND_PID

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

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.

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.

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.

In the varlistentry, I suggest we add "This variable is unset when the
connection is lost." after "but can be changed or unset.