Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
| От | Andres Freund | 
|---|---|
| Тема | Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta | 
| Дата | |
| Msg-id | hoyzuae4eugcnofactgxsi4tw5olcumdmytl2o6fxwwamfujhr@26aulxfhj37o обсуждение исходный текст  | 
		
| Ответ на | Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta ("Jelte Fennema-Nio" <postgres@jeltef.nl>) | 
| Ответы | 
                	
            		Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
            		
            		 | 
		
| Список | pgsql-hackers | 
Hi, On 2025-11-03 15:46:10 +0100, Jelte Fennema-Nio wrote: > From 31851ddff8cb40f732aac0bfac364da61ed9fa30 Mon Sep 17 00:00:00 2001 > From: Jelte Fennema-Nio <postgres@jeltef.nl> > Date: Thu, 23 Oct 2025 15:08:52 +0200 > Subject: [PATCH v3 2/2] libpq: Request protocol version 3.9999 to GREASE the > ecosystem > > The main reason that libpq does not request protocol version 3.2 by > default is because other proxy/server implementations don't implement > the negotiation. This is a bit of a chicken and egg problem: We don't > bump the default version that libpq asks, but proxies will only > implement version negotiation when their users run into issues. > This patch defines 3.999 as an explicitly unsupported protocol version > number and _pq_.test_protocol_negotiation as an explicitly unsupported > protocol extension. It also starts requesting that version and protocol > extension by default. This change to the default will be reverted before > we release PG19 release candidates (when exactly to revert before that > time is TBD). The intent is to stress test the ecosystem for > servers/middleware that don't support protocol version negotiation, so > that those servers/middleware can implement the negotiation. This is > similar to the GREASE[1] mechanism that TLS has. > > It's still possible for users to connect to servers that don't support > protocol negotiation by using max_protocol_version=3.0 in their > connection string. Only the default connection behaviour is impacted. > > [1]: https://www.rfc-editor.org/rfc/rfc8701.html Won't this mean that it'll be harder to performance comparisons between the in-development version and other versions? Because there will be negotiation before we branch of 19, but not after and not in release branches? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: