On Thu, May 16, 2024 at 5:22 AM Jelte Fennema-Nio <m...@jeltef.nl> wrote: > If we're not setting the protocol parameter in the StartupMessage, > there's currently no way for us to know if the protocol parameter is > supported by the server. If protocol parameters were unchangable then > that would be fine, but the whole point of introducing ParameterSet is > to make it possible to change protocol parameters on an existing > connection. Having the function SupportsProtocolCompression return > false, even though you can enable compression just fine, only because > we didn't ask for compression when connecting seems quite silly and > confusing.
You're probably not going to like this answer, but I feel like this is another sign that you're trying to use the protocol extensibility facilities in the wrong way. In my first reply to the thread, I proposed having the client send _pq_.protocol_set=1 in that startup message. If the server accepts that message, then you can send whatever set of message types are associated with that option, which could include messages to list known settings, as well as messages to set them. Alternatively, if we used a wire protocol bump for this, you could request version 3.1 and everything that I just said still applies. In other words, I feel that if you had adopted the design that I proposed back in March, or some variant of it, the problem you're having now wouldn't exist. IMHO, we need to negotiate the language that we're going to use to communicate before we start communicating. We should find out which protocol version we're using, and what protocol options are accepted, based on sending a StartupMessage and receiving a reply. Then, after that, having established a common language, we can do whatever. I think you're trying to meld those two steps into one, which is understandable from the point of view of saving a round trip, but I just don't see it working out well. What we can do in the startup message is extremely limited, because any startup messages we generate can't break existing servers, and also because of the concerns I raised earlier about leaving room for more extension in the future. Once we get past the startup message negotiation, the sky's the limit! -- Robert Haas EDB: http://www.enterprisedb.com