Re: [Patch] New psql prompt substitution %r (m = master, r = replica) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [Patch] New psql prompt substitution %r (m = master, r = replica)
Date
Msg-id 20160818150520.GA953993@alvherre.pgsql
Whole thread Raw
In response to Re: [Patch] New psql prompt substitution %r (m = master, r = replica)  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Responses Re: [Patch] New psql prompt substitution %r (m = master, r = replica)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Aleksander Alekseev wrote:

> Peter has a good point that in general case it's more complicated than
> just master or replica. I also agree with David that what actually
> would be nice to have is a some syntax that allows user to execute
> arbitrary commands before displaying a prompt. This way user could
> display any information he or she wants, in any format. As we can see
> it's quite doable now but probably too complicated and ugly.
> 
> Still I don't think that many users have a problem discussed in this
> thread, i.e. updating a prompt on the fly. Probably introducing a new
> syntax (I personally don't even have a good idea how exactly it should
> look like), not mentioning implementing and supporting it, doesn't
> worth an effort. Maybe there is a simpler way.
> 
> Let's say we introduce a new variable EXPORT_CONNECTION_STRING.

Bash has PROMPT_COMMAND, which is executed prior to issuing each prompt.
What about introducing such a feature into psql?  Then the \gset command
you had in your first post could be used to set the variable correctly
just before each prompt.

One issue is what to do if psql is in an aborted transaction state
(since the query would fail to run at all); in that case I suppose it
should simply not run the command at all: the feature would be
documented to run the query only when the connection is in a known good
state.

There might be other corner cases to think about, but I think it's
enough to limit the feature to work when the query is reasonable -- I
mean, if the user enters something stupid (say, something that causes
errors to be raised or creates savepoints), it's not on psql to behave
sanely.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Next
From: Andres Freund
Date:
Subject: Re: Pluggable storage