On Tue, 20 Aug 2024 at 23:48, Jacob Champion <jacob.champ...@enterprisedb.com> wrote: > That guarantee (if adopted) would also make it possible for my use > case to proceed correctly, since a libpq client can still speak 3.0 > packets on the socket safely.
Not necessarily (at least not how I defined it). If a protocol parameter has been configured (possibly done by default by libpq), then that might not be the case anymore. So, you'd also need to compare the current values of the protocol parameters to their expected value. > But in that case, PQprotocolVersion > should keep returning 3, because there's an explicit reason to care > about the major version by itself. I agree that there's a reason to care about the major version then, but it might still be better to fail hard for people that care about protocol details. Because when writing the code that checked PQprotocolVersion there was no definition at all of what could change during a minor version bump. So there was no possibility to reason for that person if they should be notified of a minor version bump or not. So notifying the author of the code by failing the check would be erring on the safe side, because maybe they would need to update their code that depends on the protocol details. If not, and they then realize that our guarantee is strong enough for their use case, then they could replace their check with something like: PQprotocolVersion() >= 3 && PQprotocolVersion() < 40000 To be clear, the argument for changing PQprotocolVersion() is definitely less strong if we'd provide such a guarantee. But I don't think the problem is completely gone either.
