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