> How about instead of talking about protocol-only GUCs (which are > indeed currently a theoretical concept), we start considering this > patch as a way to modify parameters for protocol extensions. Protocol > extension parameters (starting with _pq_.) can currently only be > configured using the StartupMessage and afterwards there is no way to > modify them. > > I believe [1], [2] and [3] from my initial email could all use such > protocol extension parameters, if those parameters could be changed > after the initial startup.
What if we allowed the client to send `ParameterStatus` messages to the server to reconfigure protocol extensions that were requested at startup? Such processing would be independent of the transaction lifecycle since protocol-level options aren't related to transactions. Any errors in the set value would be handled with an `ErrorResponse` (including if an extension was not reconfigurable after connection startup), and success with a new `ReadyForQuery` message. The actual effect of an extension change must be delayed until after the ReadyForQuery has been transmitted, though I don't know if that is feasible or if we would need to instead implicitly assume changes were successful and just close the connection on error. We wouldn't need to bump the protocol version since a client wouldn't (shouldn't) send these messages unless it successfully negotiated the relevant protocol extension(s) at startup.
