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 <http://flexmls.com>® and Spark Platform <http://sparkplatform.com> c...@fbsdata.com On Tue, Apr 26, 2016 at 11:02 AM, Steve Crawford < scrawf...@pinpointresearch.com> wrote: > 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. >> >> 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) >> >> > 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 > >
