On Thu, Jun 17, 2021 at 08:15:42PM +0100, Dagfinn Ilmari Mannsåker wrote: > 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
pygresql is also using pg_config --version: setup.py- wanted = self.escaping_funcs setup.py: supported = pg_version >= (9, 0) -- setup.py- wanted = self.pqlib_info setup.py: supported = pg_version >= (9, 1) -- setup.py- wanted = self.ssl_info setup.py: supported = pg_version >= (9, 5) -- setup.py- wanted = self.memory_size setup.py: supported = pg_version >= (12, 0) -- Justin
