From: | Jerry Sievers <gsievers19(at)comcast(dot)net> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Feature request: make cluster_name GUC useful for psql prompts |
Date: | 2016-05-06 18:42:41 |
Message-ID: | 86k2j7yqn2.fsf@jerry.enova.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 5/5/16 9:21 PM, Steve Crawford wrote:
>
>> Adding an escape sequence that references cluster_name would enable
>> prompts to identify the cluster in a manner that is both consistent and
>> distinct regardless of access path.
>
> I think that would be a good idea. You could probably design it so
> that any server parameter reported to the client can be put in a psql
> prompt.
The OP can easily work around that lack of support with something such as follow...
Add this to ~/.psqlrc[-optional version stuff]
select setting as cluster_name from pg_settings where name = 'cluster_name' -- do not simicolon terminate this line
\gset
\set PROMPT1 :cluster_name ': how cool is this:'
>
>> Potential issues/improvements:
>>
>> What should the escape-sequence display if cluster_name is not set or
>> the cluster is a pre-9.5 version. %M? %m?
>>
>> In future server versions should there be a default for cluster_name if
>> it is not set? If so, what should it be? Would the server canonical
>> hostname + listen-port be reasonable?
>
> Those are good questions. I don't really like the proposed answers,
> because that could cause confusion in practical use.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 312.241.7800
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-05-06 18:52:29 | Re: pgsql: Add TAP tests for pg_dump |
Previous Message | Merlin Moncure | 2016-05-06 18:38:17 | Re: NOT EXIST for PREPARE |