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