Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Sat, Aug 17, 2024 at 5:32 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)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