Re: proposal: psql: show current user in prompt

so 27. 1. 2024 v 0:04 odesílatel Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
napsal:

> On Fri, 26 Jan 2024 at 21:35, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > I see a possibility of disabling reporting as possibly dangerous.
> Without reporting encoding you can break psql. So it should be limited just
> to few values where is known behave.
>
> I agree that client_encoding is a GUC that likely all clients would
> want to request reporting for, so I can see the argument for always
> sending it. But I wouldn't call it dangerous for a client to be able
> to disable reporting for it. Ultimately the client is the one that
> decides. A client might just as well completely ignore the reported
> value.
>

Until now, it is not possible to disable reporting. So clients can expect
so reporting is workable.

Do you have a use case, when disabling some of the defaultly reported GUC
makes sense?

My patch doesn't protect these GUC, and now I think it is a mistake.

>
> >> While I agree it's a little bit less friendly, I think you're
> >> overestimating the difficulty of using my proposed approach. Most
> >> importantly there's no need to parse the current GUC value. A client
> >> always knows what variables it wants to have reported. So anytime that
> >> changes the client can simply regenerate the full list of gucs that it
> >> wants to report and send that. So something similar to the following
> >> pseudo code (using += for string concatenation):
> >
> >
> > I disagree with this - I can imagine some proxies add some own reported
> GUC and the client can know nothing about it.
>
> I've definitely thought about this case, since it's the main case I
> care about as maintainer of PgBouncer. And a client wouldn't need to
> know about the extra GUCs that the proxy requires for the proxy to
> work correctly. A proxy can quite simply handle this itself in the
> following manner: Whenever a client sends a ParameterSet for
> _pq_.report_parameters, the proxy could forward to the server after
> prepending its own extra GUCs at the front. The proxy wouldn't even
> need to parse the list from the client to be able to do that. An even
> better behaving proxy, should parse the list of GUCs though and would
> only forward the ParameterStatus messages that it receives from the
> server if the client requested ParameterStatus updates for them.
>

yes, inside gradual connect you can enhance the list of custom reported GUC
easily.

but for use cases like prompt in psql, I need to enable, disable reporting
- but this use case should be independent of "protected" connection related
GUC reporting.

For example - when I disable %N, I can disable reporting "role" and disable
showing role in prompt. But when "role" should be necessary for pgbouncer,
then surely the disabling reporting should be ignored. The user by setting
a prompt should not break communication. And it can be ignored without any
issue, there is not performance issue, because "role" is still necessary
for pgbouncer that is used for connection. Without described behaviour we
should not implement controlling reporting to psql, because there can be a
lot of unhappy side effects in dependency if the user set or unset custom
prompt or some other future feature.