Re: psql color hostname prompt

Поиск
Список
Период
Сортировка
От Francisco Olarte
Тема Re: psql color hostname prompt
Дата
Msg-id CA+bJJbw-FDi-oLD6chut+sbD_s8m5Tgsc6N0et5XB118jE=yoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql color hostname prompt  (Cal Heldenbrand <cal@fbsdata.com>)
Ответы Re: psql color hostname prompt  (Steve Crawford <scrawford@pinpointresearch.com>)
Список pgsql-general
Hi Cal:

On Tue, Apr 26, 2016 at 5:20 PM, Cal Heldenbrand <cal@fbsdata.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.

I do this (ssh'ing) too. What I do when it matters ( connecting to
many similar servers at a time ) is to use host connections for
everything ( so %M works, and the overhead of using local ip
connections vs unix domain sockets is nearly zero these days ).

> 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)

mmm, strong -1 for this. I would vote for another mechanism, but I
think it must reflect the real connection, after all I can typically
connect to [local], 127.0.0.1/localhost, $(hostname -i)/$(hostname)
and they are different things. A %nice_name would be ok for me, ( and
I think easy to do, just do 'if (local) expand hostname else expand
whatever %M does'. Also, you could precede it by something, or print
it like '[local=host.na.me]' without disturbing present %M usage.

> 3)  a forked process for every prompt
> While this also isn't very elegant, it seems to work fine.

Not an elegance concern, and forking is what shells do every time, so
fine for me.

> It would be nice if there was a way to do some kind of templating script
> with the psqlrc file.  Something that would dynamically generate the "\set
> PROMPT" commands on psql startup, rather than calling out to a shell every
> command.  (I'm thinking along the lines of ERB for Ruby, Django for Python,
> etc.)

That can be done with a named pipe ;->  ( or with an alias / function
using getopt to parse the options before forwarding them to psql ).
But, which just \sets $hostname in a var and uses it. )  Anyway, the
problem with this is that if you do \connect to another. You could do
something similar to this using only psql/psqlrc tricks:

cdrs=> \set fecha `date`
cdrs=> \echo :fecha
Wed Apr 27 10:23:22 CEST 2016

Here you would use your script instead of fecha, and interpolate it
using %:fecha: in the prompt.

And now the second step of the trick:
cdrs=> \set recalc '\\set fecha `date`'
cdrs=> \echo :recalc
\set fecha `date`
cdrs=> :recalc
cdrs=> \echo :fecha
Wed Apr 27 10:24:07 CEST 2016
cdrs=> :recalc
cdrs=> \echo :fecha
Wed Apr 27 10:24:16 CEST 2016

Now you can use :recalc if you do connect to have the prompt updated.

Anyway, TIMTOWTDI.

> But again, I think the more elegant approach is to alter the %M logic.
> Any thoughts?

At risk of being redundant, not altering %M, another %x better.

Francisco Olarte.


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

Предыдущее
От: Victor Yegorov
Дата:
Сообщение: Re: Slow join over three tables
Следующее
От: Ihnat Peter | TSS Group a.s.
Дата:
Сообщение: Re: Background worker with Listen