From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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:15:44 |
Message-ID: | CA+TgmobUeWHRYTbtEAio35pUGn7zRYtjo+2oHLm4WNTvLeJw0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 17, 2021 at 1:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> We don't really add major new APIs to libpq very often, so I don't
> find that too compelling. I do find it compelling that user code
> shouldn't embed knowledge about "feature X arrived in version Y".
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.
Some of those releases also changed behavior. For example, version 10
allowed multi-host connection strings and URLs. People might want to
know about that sort of thing, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-06-17 18:17:15 | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Previous Message | Daniel Gustafsson | 2021-06-17 18:03:18 | Re: Add version macro to libpq-fe.h |