Re: psql color hostname prompt

From: Francisco Olarte <folarte(at)peoplecall(dot)com>
To: Cal Heldenbrand <cal(at)fbsdata(dot)com>
Cc: 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-27 08:29:23
Message-ID: CA+bJJbw-FDi-oLD6chut+sbD_s8m5Tgsc6N0et5XB118jE=yoA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Cal:

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

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ihnat Peter | TSS Group a.s. 2016-04-27 08:40:49 Re: Background worker with Listen
Previous Message Victor Yegorov 2016-04-27 06:14:27 Re: Slow join over three tables