Re: proposal: psql: show current user in prompt - Mailing list pgsql-hackers

On Sat, 27 Jan 2024 at 08:35, Pavel Stehule <pavel.stehule@gmail.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.

> 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"
shouldbe necessary for pgbouncer, then surely the disabling reporting should be ignored. The user by setting a prompt
shouldnot break communication.  And it can be ignored without any issue, there is not performance issue, because "role"
isstill necessary for pgbouncer that is used for connection. Without described behaviour we should not implement
controllingreporting to psql, because there can be a lot of unhappy side effects in dependency if the user set or unset
customprompt 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.

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.