Re: psql color hostname prompt

Поиск
Список
Период
Сортировка
От Cal Heldenbrand
Тема Re: psql color hostname prompt
Дата
Msg-id CAAcwKhf2_+8ixdHwms9ZijbOmFBqY_hO1dhGao=7+dBVEXAV7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql color hostname prompt  (Steve Crawford <scrawford@pinpointresearch.com>)
Список 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® and Spark Platform
   cal@fbsdata.com

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


В списке pgsql-general по дате отправления:

Предыдущее
От: "Mike Sofen"
Дата:
Сообщение: Re: truncate table getting blocked
Следующее
От: Peter Devoy
Дата:
Сообщение: Does this perf output seem 'normal'?