Would it be reasonable to just take the simple approach with same algorithm I used in the shell script? Basically: If the psql client uses a local UNIX domain socket, or localhost TCP connection, use the string output by "hostname" system command. From the C perspective, this is just calling the uname(2) and/or gethostname(2) system call.
All other remote connections would then fall back to the current %M functionality.
---------------------------------------------------------------
Cal Heldenbrand
Web Operations at FBS
Creators of flexmls® and Spark Platform
cal@xxxxxxxxxxx
On Tue, Apr 26, 2016 at 11:02 AM, Steve Crawford <scrawford@xxxxxxxxxxxxxxxxxxxx> wrote:
Perhaps the more elegant route here, is to change psql's behavior with %M when connected to the local machine? (This would also solve point #3)2) %M vs shell call%M on when connected to the local machine displays the string "[local]" which I didn't like. I wanted a real hostname to show no matter which client/server pair I was using. Zero chance for mistaken commands on the wrong host. Many times we ssh to a remote server, then run psql locally.There is a basic problem - what is the hostname?1.2.3.4? db23.example.com? server42? 127.0.0.1? 192.168.54.23? Those could all be the same PostgreSQL instance, all different or some mix. And we haven't even considered local Unix connections, servers running on different ports and the fact that localhost is machine specific and non-fully-qualified names that depend on resolver search orders.One possible solution would be to essentially do the reverse of application_name. I.e. do something along the lines of adding a server-side parameter to specify the name of the server instance that would be exchanged in the startup handshake and made available to client processes.I could see some value in that but can't speak to the work and possible wire-protocol breakage that might be involved relative to the benefits.Cheers,Steve
