Question and suggestion about application binary compatibility policy

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.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