Tom Lane <t...@sss.pgh.pa.us> writes: > Robert Haas <robertmh...@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
