Re: proposal: psql: show current user in prompt

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

> On Sat, 27 Jan 2024 at 08:35, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > Until now, it is not possible to disable reporting. So clients can
> expect so reporting is workable.
>
> Sure, so if we leave the default as is that's fine. It's not as if
> this GUC would be changed without the client knowing, the client would
> be the one changing the GUC and thus disabling the sending of
> reporting for the default GUCs. If it doesn't want to disable the
> reporting, than it simply should not send such a request.
>
> > Do you have a use case, when disabling some of the defaultly reported
> GUC makes sense?
>
> Mostly if the client doesn't actually use them, e.g. I expect many
> clients don't care what the current application_name is. But I do
> agree this is not a very strong usecase, so I'd be okay with always
> sending the ones that we sent as default for now. But that does make
> the implementation more difficult, since we'd have to special case
> these GUCs instead of having the same consistent behaviour for all
> GUCs.
>

client_encoding, standard_conforming_strings, server_version,
default_transaction_read_only, in_hot_standby
and scram_iterations
are used by libpq directly, so it can be wrong to introduce the possibility
to break it.

> > 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.
>
> Maybe I'm misunderstanding what you're saying, but it's not clear to
> me why you are seeing two different use cases here. To me if we have
> the ParameterSet message then they are both the same. When you enable
> %N you would send a ParamaterSet message for _pq_.report_parameters
> and set it to a list of gucs including "role". And when you disable %N
> you would set _pq_.report_parameters to a list of GUCs without "role".
> Then if any proxy still needed "role" even if the list it receives in
> _pq_.report_parameters doesn't contain it, then this proxy would
> simply prepend "role" to the list of GUCs before forwarding the
> ParameterSet message.
>

Your scenario can work but looks too fragile. I checked - GUC now cannot
contain some special chars, so writing parser should not be hard work. But
your proposal means the proxy should be smart about it, and have to check
any change of _pq_.report_parameters, and this point can be fragile and a
source of hardly searched bugs.

>
> Also to be clear, having a "protected" connection-start only GUC is
> problematic for proxies. Because they need to update this setting
> while the connection is active when they hand of one server connection
> to another client.
>

This is true, but how common is this situation? Probably every client that
uses one proxy will use the same defaultly reported GUC. Reporting has no
extra overhead. The notification is reduced. When there is a different set
of reported GUC, then the proxy can try to find another connection with the
same set or can reconnect. I think so there is still opened question what
should be correct behaviour when client execute RESET ALL or DISCARD ALL.
Without special protection the communication with proxy can be broken - and
we use GUC for reported variables, then my case, prompt in psql will be
broken too. Inside psql I have not callback on change of reported GUC. So
this is reason why reporting based on mutable GUC is fragile :-/

Pavel