Re: Feature request: make cluster_name GUC useful for psql prompts

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

In response to

Responses

Browse pgsql-hackers by date

  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