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