On Wed, Jun 5, 2024 at 5:16 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > I agree longcancelkey=true is not what we want. In my patch 0004, you > can specify max_protocol_version=latest to use the latest protocol > version as opt-in. This is a future proof version of > protocolversion=3.1 that you're proposing, because it will > automatically start using 3.2 when it comes out. So I think that > solves your concern here. (although maybe it should be called > latest-3.x or something, in case we ever want to add a 4.0 protocol, > naming is hard) > > I personally quite like the max_protocol_version connection parameter. > I think even for testing it is pretty useful to tell libpq what > protocol version to try to connect as. It could even be accompanied > with a min_protocol_version, e.g. in case you only want the connection > attempt to fail when the server does not support this more secure > cancel key.
This makes some sense to me. I don't think that I believe max_protocol_version=latest is future-proof: just because I want to opt into this round of new features doesn't mean I feel the same way about the next round. But it may still be a good idea. I suppose the semantics are that we try to connect with the version specified by max_protocol_version and, if we get downgraded by the server, we abort if we end up below min_protocol_version. I like those semantics, and I think I also like having both parameters, but I'm not 100% sure of the naming. It's a funny use of "max" and "min", because the max is really what we're trying to do and the min is what we end up with, and those terms don't necessarily bring those ideas to mind. I don't have a better idea off-hand, though. -- Robert Haas EDB: http://www.enterprisedb.com
