On 15/08/2024 23:20, Robert Haas wrote:
> On Thu, Aug 15, 2024 at 1:13 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Added a "protocol_version" libpq option for that. It defaults to "auto",
>> but you can set it to "3.1" or "3.0" to force the version. It makes it
>> easier to test that the backwards-compatibility works, too.
>
> Over on the "Add new protocol message to change GUCs for usage with
> future protocol-only GUCs" there is a lot of relevant discussion about
> how bumping the protocol version should work. This thread shouldn't
> ignore all that discussion. Just to take one example, Jelte wants to
> bump the protocol version to 3.2, not 3.1, for some reasons that are
> in the commit message for the relevant patch over there.
Ok, I've read through that thread now, and opined there too. One
difference is with libpq option name: My patch adds "protocol_version",
while Jelte proposes "max_protocol_version". I don't have strong
opinions on that. I hope the ecosystem catches up to support
NegotiateProtocolVersion quickly, so that only few people will need to
set this option. In particular, I hope that there will never be need to
use "max_protocol_version=3.2", because by the time we introduce version
3.3, all the connection poolers that support 3.2 will also implement
NegotiateProtocolVersion.
--
Heikki Linnakangas
Neon (https://neon.tech)
