| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:03:18 |
| Message-ID: | 517462ED-0533-44D4-B3ED-35BBD53FC6ED@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 17 Jun 2021, at 19:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> A more critical point is that if pg_config is present, it'll likely
> contain the server version, which might not have a lot to do with the
> libpq version. Debian's already shipping things in a way that decouples
> those, and I gather Red Hat is moving in that direction too.
>
> I think what people really want to know is "if I try to call
> PQenterPipelineMode, will that compile?".
I think this is the most compelling argument for feature-based gating rather
than promote version based. +1 on doing "#ifdef LIBPQ_HAS_PIPELINING" or along
those lines and try to be consistent going forward. If we've truly failed to
do so in X releases time, then we can revisit this.
--
Daniel Gustafsson https://vmware.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-06-17 18:15:44 | Re: Add version macro to libpq-fe.h |
| Previous Message | Julien Rouhaud | 2021-06-17 18:00:55 | Re: Centralizing protective copying of utility statements |