On Mon, May 30, 2016 at 03:04:24AM +0000, Tsunakawa, Takayuki wrote:
> Hello,
>
> I'd like to ask you about the policy of application binary compatibility.
> And have a suggestion as well.
>
> QUESTION
> ==================================================
>
> My customer asked me if the following usage is correct.
>
> - Build an embedded SQL C application with PostgreSQL 9.2.
> - Distribute the app without ecpg nor libpq libraries. Require users to
> install PostgreSQL client which includes ecpg and libpq libraries.
> - Use the app with newer PostgreSQL major versions without rebuilding the
> app. That is, the users just replaces the PostgreSQL client.
>
> I expect this is legal, because the so_major versions of ecpg and libpq are 6
> and 5 respectively for all PostgreSQL 9.x versions so far. However, I could
> not find any description of this binary compatibility policy in the manual,
> so I haven't been able to answer the customer.
>
> What's the official policy of application binary compatibility? I found the
> same discussion in the below thread, but I'm afraid any clear answer wasn't
> given:
>
> https://www.postgresql.org/message-id/522f0b6b.1040...@4js.com
>
>
> SUGGESTION
> ==================================================
>
> How about adding an article about application binary compatibility in the
> following section, as well as chapters for libpq, ECPG, etc?
>
> 17.6. Upgrading a PostgreSQL Clust
> https://www.postgresql.org/docs/devel/static/upgrading.html
>
> There are three kinds of application assets that users are concerned about
> when upgrading. Are there anything else to mention?
>
> * libpq app
> * ECPG app
> * C-language user defined function (and other stuff dependent on it, such as
> extensions, UDTs, etc.)
I know this thread is old but it bounced around a lot of ideas. I think
there are some open questions:
* Will a new application link against an older minor-version libpq?
* Will an old application link against a newer minor-version libpq?
I think we are all in agreement that a binary cannot run using a libpq
with a different major version number.
We have this text in src/tools/RELEASE_CHANGES:
Major Version
=============
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not limited to:
1. Removing a public function or structure (or typedef, enum, ...)
2. Modifying a public functions arguments.
3. Removing a field from a public structure.
4. Adding a field to a public structure, unless steps have been
previously taken to shield users from such a change, for example by
such structures only ever being allocated/instantiated by a library
function which would give the new field a suitable default value.
Adding a new function should NOT force an increase in the major version
number. (Packagers will see the standard minor number update and install
the new library.) When the major version is increased all applications
which link to the library MUST be recompiled - this is not desirable.
When
the major version is updated the minor version gets reset.
Minor Version
=============
The minor version number should be updated whenever the functionality of
the library has changed, typically a change in source code between
releases
would mean an increase in the minor version number so long as it does
not
require a major version increase.
Given that we make at least minor changes to our libraries in every
major
PostgreSQL version, we always bump all minor library version numbers at
the
start of each development cycle as a matter of policy.
This is saying running against a mismatched minor version should be fine
for a binary.
ecpg is a little tricker because it has knowledge of SQL data types and
might not support certain features if the ecpg library isn't _run_
against the same major server version. My guess is that older ecpg
libraries will run fine against newer servers, but the opposite might
not be true.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
