Re: proposal: psql: show current user in prompt

ne 28. 1. 2024 v 22:52 odesílatel Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
napsal:

> On Sun, 28 Jan 2024 at 20:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > There is another reason - compatibility with other drivers. We maintain
> just libpq, but there are JDBC, Npgsql, and some native 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).
>

ok

>
> > 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.
>

because there is not 100% isolation of different layers, there is one
resource that can be modified by network layer (proxy) and by application
layer (psql). Unfortunately, I don't see any better solution, how these
layes separated.

>
> > From my perspective the situation can be better if I know so defaultly
> reported GUC are fixed, and cannot be broken. Then for almost all clients
> (without pgbouncer users), the CUSTOM_REPORT_GUC GUC will contain just
> "role", and then the risk is minimal.
>
> Which risk are you talking about here?
>

The risk of not wanted reporting. I'll return to my psql prompt case. Who
will disable reporting of "rule", when psql crashes? pgbouncer will call
DISCARD ALL before reuse connection, but it ignores
_pq_.report_parameters/';.>"

>
> > But still there are problems with handling of RESET ALL - so that means
> I need to do a recheck of the local state every time, 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_REPORT on "role" GUC. Maybe
> the introduction of a new flag for DISCARD can solve it. But again there
> can be a problem for 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).
>

ok, this can work, and this is the reply to my previous query.

Regards

Pavel