Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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.)
FWIW, the perl DBD::Pg module extracts the version number from
`pg_config --version` at build time, and uses that to define a
PGLIBVERSION which is used to define fatal fallbacks for a few
functions:
https://metacpan.org/release/TURNSTEP/DBD-Pg-3.15.0/source/dbdimp.c#L26-55
I have an unfinished branch which does similar for PQsetSingleRowMode,
(added in 9.2).
- ilmari