Re: proposal: psql: show current user in prompt

On Sun, 28 Jan 2024 at 20:01, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> There is another reason - compatibility with other drivers.  We maintain just libpq, but there are JDBC, Npgsql, and
somenative Python drivers. I didn't checked, but maybe they expect GUC with GUC_REPORT flag. 

This doesn't matter, because these drivers themselves would only stop
receiving certain GUC report messages if they changed this the
_pq_.report_paramers GUC. And at that point the other driver is
disabling the reporting on purpose. But like I said, I'm fine with
forcing the currently default GUC_REPORT GUCs to be GUC_REPORT always
(maybe excluding application_name).

> But now, I don't see any design without problems. Your look a little bit fragile to me,

Can you explain what still looks fragile to you about my design? Like
I explained at least from a proxy perspective this is the least
fragile imho, since it can reuse already existing and battle tested
code.

> From my perspective the situation can be better if I know so defaultly reported GUC are fixed, and cannot be broken.
Thenfor almost all clients (without pgbouncer users), the CUSTOM_REPORT_GUC GUC will contain just "role", and then the
riskis minimal. 

Which risk are you talking about here?

> But still there are problems with handling of RESET ALL - so that means I need to do a recheck of the local state
everytime, when I will show a prompt with %N - that is not nice, but probably with a short list it will not be a
problem.

I'm not entirely sure what you mean here. Is this still a problem if
RESET ALL is ignored for _pq_.report_parameters? If so, what problem
are you talking about then?

> But I can imagine a client crash, and then pgbouncer executes RESET ALL, and at this moment I would like to reset
GUC_REPORTon "role" GUC. Maybe the introduction of a new flag for DISCARD can solve it. But again there can be a
problemfor which GUC the flag GUC_REPORT should be removed, because there are not two independent lists. 

I don't think this is a problem. PgBouncer wouldn't rely on RESET ALL
to reset the state of _pq_.report_parameters. Before handing off the
old connection to a new client, PgBouncer would simply change the
_pq_.report_parameters GUC back to its default value by sending a
ParameterSet message. i.e. PgBouncer would use the same logic as it
currently uses to correctly reset tracked GUCs (application_name,
client_encoding, etc).