On Tue, Jan 16, 2024 at 8:43 AM Jelte Fennema-Nio <m...@jeltef.nl> wrote: > I haven't removed 0008 yet, since I'd like some feedback first if that > makes sense. But I did add two new patches in the middle of the > patchset (which shift the later patch numbers by 2): > > 0007: Adds a new \parameterset meta-command to psql to be able to more > easily test the new ParameterSet message > > 0008: Shows warning in psql if the server is not supporting the newest > protocol version.
Sorry for not getting back to this right away; there are quite a few threads competing for my attention. I think it's flat-out not viable to bump the protocol version to 3.1 any time in the next few years. NegotiateProtocolVerison has existed since ae65f6066dc3d19a55f4fdcd3b30003c5ad8dbed (2017-11-21, 11.0, 10.2, 9.6.7, 9.5.11, 9.4.16, 9.3.21), but libpq didn't handle it until bbf9c282ce92272ed7bf6771daf0f9efa209e61b (2022-11-17, 16.0) -- and even that handling doesn't really seem like what we want, because it looks like it will reject anything where the protocol version doesn't match exactly, rather than downgrading. To fix that, I think we need some parts of what you've got in 0002, where we have an earliest and a latest minor protocol version that we'll accept, and the server is allowed to downgrade from the latest thing we support, just as long as they don't try to downgrade below the earliest thing we support. But I think we would want to have those changes in all supported branches before we could think of requesting 3.1 or higher by default. Imagine that in v17 we both added server support for protocol version 3.1 and also adopted your 0001. Then, a v17 libpq would fail to connect to a v16 or earlier PostgreSQL instance. In effect, it would be a complete wire compatibility break. There's no way that such a patch is going to be acceptable. If I were to commit a patch from you or anyone else that does that, many angry people would show up to yell at both of us. So unless I'm misunderstanding the situation, 0001 is pretty much dead on arrival for now and for quite a while to come. That doesn't necessarily mean that we couldn't *optionally* request 3.1, e.g. controlled by a connection keyword. I would imagine that the user would write e.g. 'user=rhaas password=banana protocolroles=true' and libpq would say "oh, because the user wanted protocolroles=true I need to request at least 3.1" -- but if that weren't there, the server would still request only 3.0 and nothing would break. Also, I'm pretty doubtful that we want PQunsupportedProtocolExtensions(). That seems like allowing the client to have too much direct visibility into what's happening at the protocol level. That kind of interface might make sense if we were trying to support unknown protocol extensions from third parties, but for stuff in core, I think there should be specific APIs that relate to specific features e.g. you call PQsetWireProtocolRole(char *whatever) and it returns success or failure according to whether that capability is available without telling you how that's negotiated on the wire. So in summary, I think parts of 0002 are a good idea, but 0001 is not realistic. -- Robert Haas EDB: http://www.enterprisedb.com
