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.
Why?
While that's probably OK, it's not especially desirable. The typical Windows deployment model involves the application bundling all its direct dependencies except when those are provided by a runtime redistributable designed for that purpose.
- Use the app with newer PostgreSQL major versions without rebuilding the app. That is, the users just replaces the PostgreSQL client.
... especially since there isn't a client-only PostgreSQL distribution Windows.
How about adding an article about application binary compatibility in the following section, as well as chapters for libpq, ECPG, etc?
It would be sensible to better define the binary compatibility expectations that clients may rely upon and, when they are broken, a managed way in which they're broken (soname bump, etc).
If you have an interest in the area it might be worth drafting a proposal after taking a look at past binary compatibility discussions on -hackers.
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.)
> On the other hand, the application will start on Windows and probably cause difficult trouble due to the incompatibility.
Yeah, we just write 'libpq.dll' on Windows.
The simplest solution would be to incorporate the soname, so it becomes libpq0509.dll for example. Like VS does with the VS runtime. The main downside is that because it's not a true soname and the OS has no such concept, the linker for everything compiled against that DLL must specify the versioned DLL name, it can't just link to 'libpq' .