Re: psql color hostname prompt

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>
cal(at)fbsdata(dot)com

On Tue, Apr 26, 2016 at 11:02 AM, Steve Crawford <
scrawford(at)pinpointresearch(dot)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
>
>