Re: proposal: psql: show current user in prompt

@Tom and @Robert, since you originally suggested extending the
protocol for this, I think some input from you on the protocol design
would be quite helpful. BTW, this protocol extension is the main
reason I personally care for this patch, because it would allow
PgBouncer to ask for updates on certain GUCs so that it can preserve
session level SET commands even in transaction pooling mode.
Right now PgBouncer can only do this for a handful of GUCs, but
there's quite a few others that are useful for PgBouncer to preserve
by default:
- search_path
- statement_timeout
- lock_timeout

And users might have others that they want to preserve others too.

On Fri, 8 Sept 2023 at 21:08, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> I think we'll need some bikeshedding on what the protocol message
>> should look like exactly. I'm not entirely sure what is the most
>> sensible here, so please treat everything I write next as
>> suggestions/discussion:
>> I see that you're piggy-backing on PQsendTypedCommand, which seems
>> nice to avoid code duplication. It has one downside though: not every
>> type, is valid for each command anymore.
>> One way to avoid that would be to not introduce a new command, but
>> only add a new type that is understood by Describe and Close, e.g. a
>> 'G' (for GUC). Then PqMsg_Describe, G would become the equivalent of
>> what'the current patch its PqMsg_ReportGUC, 't' and PqMsg_Close, G
>> would be the same as PqMsg_ReportGUC, 'f'.
>
>
> I am sorry, I don't understand this idea?

To clarify what I meant: I meant instead of introducing a new top
level message type (i.e. your newly introduced ReportGUC message), I
suggested adding a new subtype that is understood by the Describe and
Close messages. In addition to being able to use Describe and Close
for statements and portals with the S and P subtypes respectively,
like you currently can, we could add a new subtype G which would start
and stop GUC reporting (with the Describe and Close message
respectively). I think that would make the client code even simpler than
it is now.