On Tue, Aug 20, 2024 at 9:02 AM Robert Haas <robertmh...@gmail.com> wrote:
> Yes. And the major * 10000 + minor convention is used in other places > already, for PG versions, so it might already be familiar to some > people. > I'm wondering why we are indicating that minor versions of the protocol are even a real thing. We should just use integer version numbers. We are on 3. The next one is 4 (the trailing .0 is just historical cruft just like with our 3-digit PostgreSQL version number). v18 libpq-based clients, if they attempt to connect using v4 and fail, will try again using the v3 connection. That will retain status quo behavior when something like a connection pooler doesn't understand the new reality. We can add a libpq option to prevent this auto-downgrade behavior. At some point users will want to use something other than the v3 current tooling supports and will put pressure on those tools to change. In the mean-time our out-of-the-box behavior continues to work using the v3 protocol. Feature detection sounds great, and maybe we want to go there eventually, but everyone understands progressive enhancement represented by version numbering. A given major server version would only support a fixed and unchanging set of protocol versions between 3 and N. On the client, if N = 7 then libpq would be able to choose both 7 and 3 as the version it tries out-of-the-box. We can use a libpq parameter to allow the client to specify something between 4 and 6 (which may fail depending on poolers and what-not). If the chain of servers supports protocol version negotiation then the attempt to connect using 7 can be auto-downgraded to anything between 3 and 6 (saving effort of a failed attempt and establishing a new one.) Leaving the client the option to specify a minimum version of the protocol it can accept. David J.
