Hi, On 2021-06-17 14:41:40 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I'm not sure I understand why you think that exposing the version number > > for libpq is such a bad idea? > > I think it'd be reasonable to add a few more carefully chosen macros to > > pg_config_ext.h. > > The primary problem I've got with that is the risk of confusion > between server and libpq version numbers. In particular, if we do > it like that then we've just totally screwed the Debian packagers. > They will have to choose whether to install pg_config_ext.h from > their server build or their libpq build. Both choices are wrong, > depending on what applications want to know.
That's a fair point. However, we kind of already force them to do so - libpq already depends on pg_config_ext.h, so they need to deal with the issue in some form. It's not particularly likely to lead to a problem to have a mismatching pg_config_ext.h, though, so maybe that's not too bad. Our make install actually forsees the issue to some degree, and installs pg_config_ext.h in two places, which then debian builds on: $ apt-file search pg_config_ext.h libpq-dev: /usr/include/postgresql/pg_config_ext.h postgresql-server-dev-13: /usr/include/postgresql/13/server/pg_config_ext.h postgresql-server-dev-14: /usr/include/postgresql/14/server/pg_config_ext.h Greetings, Andres Freund
