On Sat, Aug 17, 2024 at 5:32 AM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > Not introducing new APIs definitely is useful to clients and the > community. Before users can use a new API, their libpq wrapper needs > to expose this new function that calls it through FFI. First of all > this requires work from client authors.
Sure, just like they do every other new libpq function. > But the **key point being**: > The new function would not be present in old libpq versions. So for > some clients, the FFI wrapper would also not exist for those old libpq > versions, or at least would fail. So now users before actually being > able to check for a minor protocol version, they first need an up to > date libpq wrapper library for their language that exposes the new > function, and then they'd still have to check their actual libpq > version, before they could finally check for the minor protocol > version... I feel like what you're really complaining about here is that libpq is not properly versioned. We've just been calling it libpq.so.5 forever instead of bumping the version number when we change stuff. Maybe we should start doing that, because that's exactly what version numbers are for. Alternatively or in addition, maybe we should have a function in libpq that returns its own PostgreSQL version, because that would solve this problem for all cases, whereas what you're proposing here only solves it for this particular case (and at the risk of breaking things for somebody). I just don't see why this particular change is special. We add new libpq interfaces all the time and we don't do anything to make that easy for libpq clients to discover. If we implemented longer cancel keys or protocol parameters or transparent column encryption without a protocol version bump, clients would still need to figure out that those features were present in the libpq they are linked against, just like they presumably already need to worry about whether they're linked a new-enough libpq to have any other feature that's been added since forever ago. Sure, that's not great, but it doesn't seem any more not great in this case than any other, and I'd rather see us come up with a nice general solution to that problem than hack this specific case by redefining an existing function. Also, I kind of wish you had brought this argument up earlier. Maybe you did and I missed it, but I was under the impression that you were just arguing that "nobody will notice or care," which is a quite different argument than what you make here. -- Robert Haas EDB: http://www.enterprisedb.com
