Re: Add version macro to libpq-fe.h

On Thu, Jun 17, 2021 at 2:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Interesting, but then you have to explain why this is the first time
> that somebody has asked for a version number in libpq-fe.h.  Maybe
> all those previous additions were indeed minor enough that the
> problem didn't come up.  (Another likely possibility, perhaps, is
> that people have been misusing the server version for this purpose,
> and have been lucky enough to not have that approach fail for them.)

Well, I don't know for sure. I sometimes find it difficult to account
for the behavior even of the small number of people I know fairly
well, let alone the rather large number of people I've never even met.
But if I had to speculate ... I think one contributing factor is that
the number of people who write applications that use a C-language
connector to the database isn't terribly large, because most
application developers are going to use a higher-level language like
Java or Python or something. And of those that do, I would guess most
of them aren't trying to write applications that work across versions,
and so the problem doesn't arise. Now I know that personally, I have
tried to do that on a number of occasions, and I've accidentally used
functions that only existed in newer versions on, err, most of those
occasions. I chose to handle that problem by either (a) rewriting the
code to use only functions that appeared in all relevant versions of
libpq or (b) upgrading all the versions of libpq in my environment to
something new enough that it would work. If I'd run into a problem
that couldn't be handled in either of those ways, I likely would have
handled it by (c) depending on some symbol that actually indicates the
server version number, and demanding that anybody compiling my code
use a packaging system where those versions were the same. But none of
those workarounds seem like a real argument against having a version
indicator for libpq proper.

> Anyway, I do not see why we can't establish a principle going forward
> that new additions to libpq's API should involve at least one macro,
> so that they can be checked for with #ifdefs.  Just because the
> version-number approach offloads work from us doesn't make it a good
> idea, because the work doesn't vanish; it will be dumped in the laps
> of packagers and end users.

What work? Including an additional #define in a header file doesn't
create any work for packagers or end-users that I can see. If
anything, it seems easier for end-users. If you want a function that
first appears in v16, just test whether the version number is >= 16.
On the other hand if we promise to add at least one #define to that
file for each new release, then somebody's got to be like, oh, let's
see, this function was added in v16, now which #define got added in
that release ... hmm, let me go diff the branches in git ... how is
that any better? Especially because it seems really likely that we
will fail to actually follow this principle consistently, in which
case they may find that #define that they need doesn't even exist.

-- 
Robert Haas
EDB: http://www.enterprisedb.com