What if we created a new guc flag `GUC_PROTOCOL_EXTENSION` (or a better name), used that for any of the GUCs options that should *only* be set via a `ParameterSet` protocol message, and then prevent changing those through SET/RESET/RESET ALL (but I don't see a reason to prevent reading them through SHOW). (I would imagine most/all `GUC_PROTOCOL_EXTENSION` GUCs would also set `GUC_NOT_IN_SAMPLE`, `GUC_DISALLOW_IN_FILE`, and maybe `GUC_NO_SHOW_ALL`.). Looking back at use cases in the original message of this thread, I would imagine at least the "configurable GUC report" and "protocol compression" would likely want to be flagged with `GUC_PROTOCOL_EXTENSION` since both would seem like things that would require low-level client involvement/support when they change.
I was already drafting this email before the last one in the thread came through, but I think this proposal addresses a few things from it: > - Since we currently don't have any protocol parameters. How do I test > it? Should I add a debug protocol parameter specifically for this > purpose? Or should my tests just always error at the moment? `protcocol_managed_params` would serve as the example/test parameter in this patch series > - If I create a debug protocol parameter, what designs should it > inherit from GUCs? e.g. parsing and input validation sounds useful. > And where should it be stored e.g. protocol_params.c? I'm thinking using flag(s) on GUCs would get useful mechanics without needing to implement an entirely separate param system. It appears there are existing flags that cover almost everything we would want except for actually marking a GUC as a protocol extension. > - How do you get the value of a protocol parameter status? Do we > expect the client to keep track of what it has sent? Do we always send > a ParameterStatus message whenever it is changed? Or should we add a > ParamaterGet protocol message too? I would think it would be reasonable for a client to track its own ParameterSets if it has a reason to care about them, since presumably it needs to do something differently after setting them anyways? Though I could see an argument for sending `ParameterStatus` if we want that to serve as an "ack" so a client could wait until it had active confirmation from a server that a new parameter value was applied when necessary. > To clarify, the main thing that I want to do is take the value from > ParameterStatus and somehow, without having to escape it, set that > value for that GUC for a different session. As explained above, I now > think that this newly proposed protocol message is a bad fit for this. > But I still think that that is not a weird thing to want. Now, for the possibly nutty part of my proposal, what if we added a GUC string list named `protcocol_managed_params` that had the `GUC_PROTOCOL_EXTENSION` flag set, which would be a list of GUC names to treat as if `GUC_PROTOCOL_EXTENSION` is set on them within the context of the session. If a client wanted to use `ParameterSet` to manage a non-`GUC_PROTOCOL_EXTENSION` managed parameter, it would first issue a `ParameterSet` to add the parameter to the `protcocol_managed_params` list, and then issue a `ParameterSet` to actually set the parameter. If for some reason (e.g. some pgbouncer use cases) the client then wanted the parameter to be settable "normally" it would issue a third `ParameterSet` to remove the parameter from `protcocol_managed_params`. Regarding transactional semantics, I *think* it would be reasonable to specify that changes made through `ParameterSet` are not transactional and that `protcocol_managed_params` itself cannot be changed while a transaction is active. That way within a given transaction a given parameter has *only* transactional semantics or has *only* nontransactional semantics, which I think avoids the potential consistency problems? I think this would both address the pgbouncer use case where it wants to be able to reflect a ParameterStatus message back to the server while being agnostic to its contents while also addressing the "SET ROLE"/"SET SESSION AUTHORIZATION" issue: a pooler would just add `session_authorization` to the `protcocol_managed_params` list and then it would have full control over the user by not passing along `ParameterSet` messages setting the user from the client. (I think it would generally be reasonable to still allow setting the role within the restricted session_authorization role, but that would be a pooler decision not a PG one.)
