On Wed, 5 Jun 2024 at 22:48, Robert Haas <robertmh...@gmail.com> wrote: > I agree that we need such a mechanism, but if the driving feature is > cancel-key length, I expect that opt-in isn't going to work very well. > Opt-in seems like it would work well with compression or transparent > column encryption, but few users will specify a connection string > option just to get a longer cancel key length, so the feature won't > get much use if we do it that way.
I know Neon wants to make use of this for their proxy (to encode some tenant_id into the key). So they might want to require people to opt-in when using their proxy. > I won't be crushed if we decide to > somehow make it opt-in, but I kind of doubt that will happen. > Would we > make everyone add longcancelkey=true to all their connection strings > for one release and then carry that connection parameter until the > heat death of the universe even though after the 1-release transition > period there would be no reason to ever use it? Would we rip the > parameter back out after the transition period and break existing > connection strings? Would we have people write protocolversion=3.1 to > opt in and then they could just keep that in the connection string > without harm, or at least without harm until 3.2 comes out? I don't > really like any of these options that well. 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.
