On Mon, 2023-04-17 at 12:17 -0400, Robert Haas wrote:
> In the case at hand, it seems like the problem could easily be solved
> by allowing the property to be changed after connection startup.
> Instead of using the protocol extension mechanism to negotiate a
> specific value for the property, we can use it to negotiate about
> whether or not some new protocol message that can be used to change
> that property is supported.
...
> Backing up a level, the purpose of the protocol extension mechanism
> is
> to help us agree on the communication protocol
Thank you, that seems like a better approach to me.
It involves introducing new message types which I didn't really
consider. We might want to be careful about how many kinds of messages
we introduce so that the one-letter codes are still managable. I've
been frustrated in the past that we don't have separate symbols in the
source code to refer to the message types (we just use literal 'S',
etc.).
Maybe we should have a single new message type 'x' to indicate a
message for a protocol extension, and then have a sub-message-type? It
might make error handling better for unexpected messages.
Also, is there any reason we'd want this concept to integrate with
connection strings/URIs? Probably not a good idea to turn on features
that way, but perhaps we'd want to support disabling protocol
extensions from a URI? This could be used to restrict authentication
methods or sources of authentication information.
> The reason why I suggest this is that I feel like there could be a
> bunch of things like this.
What's the trade-off between having one protocol extension (e.g.
_pq_protocol_session_parameters) that tries to work for multiple cases
(e.g. binary_formats and session_user) vs just having two protocol
extensions (_pq_set_session_user and _pq_set_binary_formats)?
> For example, one
> that would be really useful for connection poolers is the session
> user. The pooler would like to change the session user whenever the
> connection is changed to talk to a different client, and it would
> like
> that to happen in a way that can't be reversed by issuing any SQL
> command.
That sounds valuable to me whether we generalize with "protocol session
parameters" or not.
Regards,
Jeff Davis