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
andlibpq libraries.
- Use the app with newer PostgreSQL major versions without rebuilding the app. That is, the users just replaces the
PostgreSQLclient.
I expect this is legal, because the so_major versions of ecpg and libpq are 6 and 5 respectively for all PostgreSQL 9.x
versionsso far. However, I could not find any description of this binary compatibility policy in the manual, so I
haven'tbeen 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'mafraid any clear answer wasn't given:
https://www.postgresql.org/message-id/522F0B6B.1040006@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.)
Regards
Takayuki Tsunakawa
