Re: Question and suggestion about application binary compatibility policy - Mailing list pgsql-hackers

From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Craig Ringer

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.

I think so, too, but I'm not confident that's typical.  Some people may think of PostgreSQL binaries as a shared component for their applications and place it in one place, just like the PostgreSQL library package is in /usr/lib/pgsql.

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

There's a client-only installation method as follows, although I haven't checked whether EnterpriseDB, OpenSCG, or any other PostgreSQL-based products provide client-only installation.

https://www.postgresql.org/docs/devel/static/install-windows-full.html#AEN30192

[Excerpt]

--------------------------------------------------

If you want to install only the client applications and interface libraries, then you can use these commands:

install c:\destination\directory client

--------------------------------------------------

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.

Sure, I'll submit a patch to pgsql-docs.  Thanks to Michael's confirmation, I could answer the customer's question, so this is not an immediate task now.  But I'll do.

- On-disk format

- Wire protocol

- SQL-level (data types, syntax, encoding handling, settings, ...)

Yes, I recognize these items.  I omitted them because:

- On-disk format: this is handled in the PostgreSQL manual article about upgrading

- Wire protocol: I believe the compatibility will be retained

- SQL-level: ditto

But if you feel a need for their compatibility description for completeness, I'll add it.  ... Yes, the explicit explanation may be necessary so that users are assured that the PostgreSQL compatibility policy matches their expectation.

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

Although I haven’t examined yet, some directive in .def file might enable applications to specify libpq.lib at build time and to link with libpq5.dll at run time.

Regards

Takayuki Tsunakawa