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.) Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
