On Fri, 26 Jan 2024 at 21:35, Pavel Stehule <pavel.steh...@gmail.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. >> 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.
