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

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

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to