Re: Details about libpq cross-version compatibility - Mailing list pgsql-docs
From | Heikki Linnakangas |
---|---|
Subject | Re: Details about libpq cross-version compatibility |
Date | |
Msg-id | 50519703.7080506@iki.fi Whole thread Raw |
In response to | Details about libpq cross-version compatibility (Sebastien FLAESCH <sf@4js.com>) |
Responses |
Re: Details about libpq cross-version compatibility
|
List | pgsql-docs |
On 13.09.2012 10:46, Sebastien FLAESCH wrote: > Thank you Heikki for your answer! > > I can write a paragraph, (hence I did never do that => where can I find > info to contribute on the doc?) Just follow the style and language of the rest of the docs the best that you can. If you can submit the changes as a patch against the SGML docs in the source repository, that would be great, but I can also easily convert it to that format if you just post the suggested text itself in an email. > But so far it's not quite clear to me: > > You write "That really shouldn't be necessary", when I write that we have > to ship different drivers for each major PostgreSQL version... > > Is this what I should document? Based on assumptions? > > Further: Today we use a simple naming convention: > > dbmpgs83x => for PostgreSQL 8.3.x > dbmpgs84x => for PostgreSQL 8.4.x > dbmpgs90x => for PostgreSQL 9.0.x > dbmpgs91x => for PostgreSQL 9.1.x > dbmpgs92x => for PostgreSQL 9.2.x > > While we need to ship 5 drivers, this is clear and simple to understand. What I meant is that it probably isn't necessary to ship 5 drivers. The latest version of libpq works against older server versions, so you could just ship one version of the dbmpgs driver (the latest), and it will work with any supported server and libpq version. If it compiles with 8.3 version of libpq, if should work with any newer version at runtime. And if you compile it with 9.2 version of libpq, it should still work at runtime with an older version of libpq, if you refrain from using any new features of libpq. However, there might be something else in your driver that's dependent on the server version, like if you construct SQL queries in the driver and you need to use different syntax against different server versions. Even that would probably be better to implement as runtime checks rather than #ifdefs in the driver, so that the latest driver would work against all supported server versions. > If a future major version (for ex 9.3) implements a new strategic feature > that makes libpq headers incompatible with prior versions, what shall we > do with our convention? Shall we ship 9.x (where 0<=x<=2) drivers and 9.3+ > drivers? What if a next major version implements again another feature > that makes headers incompatible again? Yes, however, we try hard to avoid doing such incompatible changes to libpq. In fact, I don't recall any such changes in the project history. Backwards-compatibility of libpq is important. If you actually use the new features added at a later libpq library, then you obviously need a new version of the library, but if you write your client program to the lowest common denominator, it will work with any version of libpq. For example, the libpq sample programs in that come with the server sources in src/test/examples all work with a different libpq version. If you take the 9.2 versions of those and run them with 8.3 version of libpq, they work, and vice versa. - Heikki
pgsql-docs by date: