Hi,
On 2021-06-17 14:41:40 -0400, Tom Lane wrote:
> Andres Freund <andres@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
