From: | Cal Heldenbrand <cal(at)fbsdata(dot)com> |
---|---|
To: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
Cc: | Francisco Olarte <folarte(at)peoplecall(dot)com>, Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: psql color hostname prompt |
Date: | 2016-04-26 17:18:11 |
Message-ID: | CAAcwKhf2_+8ixdHwms9ZijbOmFBqY_hO1dhGao=7+dBVEXAV7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Devoy | 2016-04-26 23:27:31 | Does this perf output seem 'normal'? |
Previous Message | Mike Sofen | 2016-04-26 16:36:32 | Re: truncate table getting blocked |