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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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).

Not really. *No* runtime test is adequate for discovery of a new
library API, because if you try to call a function that doesn't exist
in the version you have, you will get a compile or link failure long
before you can call any inquiry function.

Bumping the .so's major version just creates another way to fail
at link time, so I'm not seeing how that would make this better.

> 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.

Indeed. But we have actually paid a little bit of attention to that,
in the form of inventing #define symbols that can be tested at compile
time. (There's an open item for 17 concerning failure to do that for
some new-in-17 APIs.) Yeah, it's grotty, but runtime checks aren't
especially relevant here.

In any case, please let us not abuse the wire protocol version number
as an indicator of the libpq-to-application API version. They are
fundamentally different things.

regards, tom lane