On Tue, 20 Aug 2024 at 19:31, Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > It's applicable to the use case I was talking about with Jelte. A > libpq client dropping down to the socket level is relying on > (implicit, currently undocumented/undecided, possibly incorrect!) > intermediary guarantees that the protocol provides for a major > version. I'm hoping we can provide some, since we haven't broken > anything yet. If we decide we can't, then so be it -- things will > break either way -- but it's still strange to me that we'd be okay > with literally zero forward compatibility and still call that a "minor > version".
I think one compatibility guarantee that we might want to uphold is something like the following: After completing the initial connection setup, a server should only send new message types or new fields on existing message types when the client has specifically advertised support for that message type in one of two ways: 1. By configuring a specific protocol parameter 2. By sending a new message type or using a new field that implicitly advertises support for the new message type/fields. In this case the message should be of a request-response style, the server cannot assume that after the request-response communication happened this new message type is still supported by the client. The reasoning for this was discussed a while back upthread: This would be to allow a connection pooler (like PgBouncer) to have a pool of the highest minor version that the pooler supports e.g 3.8, but then it could still hand out these connections to clients that connected to the pooler using a lower version. Without having these clients receive messages that they do not support. Another way of describing this guarantee: If a client connects using 3.8 and configures no protocol parameters, the client needs to handle anything 3.8 specific that the handshake requires (such as longer cancel token). But then after that handshake it can choose to send only 3.0 packets and expect to receive only 3.0 packets back.
