Robert Haas <robertmhaas@gmail.com> writes:
> I just went and looked at how exports.txt has evolved over the years.
> Since PostgreSQL 8.1, every release except for 9.4 and 11 added at
> least one new function to libpq. That means in 14 releases we've done
> something that might break someone's compile 12 times. Now maybe you
> want to try to argue that few of those changes are "major," but I
> don't know how that could be a principled argument. Every new function
> is something someone may want to use, and thus a potential compile
> break.
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.)
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.
BTW, by that principle, we should likely be adding a symbol
associated with the new tracing features, as well as one for
pipelining. Or is it good enough to tell people they can
check "#ifdef PQTRACE_SUPPRESS_TIMESTAMPS" ?
regards, tom lane
