Re: Feature request: make cluster_name GUC useful for psql prompts
От | Jerry Sievers |
---|---|
Тема | Re: Feature request: make cluster_name GUC useful for psql prompts |
Дата | |
Msg-id | 86k2j7yqn2.fsf@jerry.enova.com обсуждение исходный текст |
Ответ на | Re: Feature request: make cluster_name GUC useful for psql prompts (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Feature request: make cluster_name GUC useful for psql prompts
|
Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.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.consulting@comcast.net p: 312.241.7800
В списке pgsql-hackers по дате отправления: