From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Boris Kolpackov <boris(at)codesynthesis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Álvaro Herrera <alvaro(dot)herrera(at)2ndquadrant(dot)com> |
Subject: | Re: Add version macro to libpq-fe.h |
Date: | 2021-06-17 18:41:40 |
Message-ID: | 1036619.1623955300@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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.
Now we could alternatively invent a libpq_version.h and hope that
packagers remember to install the right version of that. But I
think it's a better user experience all around to do it the other
way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-06-17 18:48:01 | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Previous Message | Tom Lane | 2021-06-17 18:34:18 | Re: Add version macro to libpq-fe.h |