Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TC46y-00064v-F3 for pgsql-docs@postgresql.org; Thu, 13 Sep 2012 07:45:20 +0000 Received: from mail231.strasbourg.4js.com ([92.103.31.231]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TC46v-0004K2-9p for pgsql-docs@postgresql.org; Thu, 13 Sep 2012 07:45:19 +0000 Received: from [10.0.0.204] (orca.strasbourg.4js.com [10.0.0.204]) (authenticated bits=0) by mail231.strasbourg.4js.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q8D7j8xG010595 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 09:45:08 +0200 Message-ID: <50518F47.30806@4js.com> Date: Thu, 13 Sep 2012 09:46:15 +0200 From: Sebastien FLAESCH Organization: Four Js Development Tools User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20111110 Lightning/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: hlinnaka@iki.fi CC: pgsql-docs@postgresql.org Subject: Re: Details about libpq cross-version compatibility References: <5050A86B.4080601@4js.com> <505184B6.6050008@iki.fi> In-Reply-To: <505184B6.6050008@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at mail231 X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail231.strasbourg.4js.com [10.10.0.1]); Thu, 13 Sep 2012 09:45:08 +0200 (CEST) X-Pg-Spam-Score: -2.4 (--) X-Archive-Number: 201209/10 X-Sequence-Number: 7462 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?) 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. 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? I think I am asking for is an official statement that clearly says that libpq headers are only compatible for a given set of minor versions, like (8.4.1, 8.4.2, 8.4.3, ...) or (9.2.1, 9.2.2, ...) I believe also that the libpq library should automatically check for compatiblity, based on PG_MAJORVERSION definition in pg_config.h ... Seb On 09/13/2012 09:01 AM, Heikki Linnakangas wrote: > On 12.09.2012 18:21, Sebastien FLAESCH wrote: >> I believe there is some info missing in the page describing libpq >> programs build: >> >> http://www.postgresql.org/docs/9.2/interactive/libpq-build.html >> >> I am working with PostgreSQL for several years now (since V7), >> maintaining a set >> of "db drivers" for our system, that can be used with the different >> PostgreSQL >> versions. >> >> We need to build our binaries for different versions of PostgreSQL, >> today it's >> from 8.3 to 9.2 ... >> >> What is the compatibility rule regarding this? >> >> Can I compile / link with a PostgreSQL 9.1 environment and deploy on 9.2 >> ??? >> >> Can I compile / link with a PostgreSQL 8.x environment and deploy on 9.x >> ??? > > If your binary is just a client application that uses libpq to speak to > the server, you can use any (supported) version of libpq with any > (supported) server version. There hasn't been any incompatible protocol > changes since version 7.4, which introduced the protocol version 3, and > even that was done in a backwards-compatible fashion so that even 9.2 > server still supports the old version 2 of the protocol. > > Now, another question is what happens if you compile your binaries > against e.g 9.1 version of libpq, but at runtime, you have 9.2 libpq > installed. I think that should work too, but not vice versa, if you use > any new functions from the 9.2 libpq library. In general, you should > have the same or higher version of libpq at runtime that the binaries > were built with. > > The version number bump from 8.x to 9.0 was made because 9.0 introduced > many new features, but from a compatibility policy point-of-view, 8.4 -> > 9.0 is no different than, say, going from 8.3 to 8.4. > >> The problem is that we have to ship several versions of the drivers >> for all >> the PostgreSQL versions that are in the support live cycle, today this is >> from 8.3 to 9.2 ... > > That really shouldn't be necessary. > >> So far, we followed the version policy as described here: >> >> http://www.postgresql.org/support/versioning >> >> I think it's ok to follow this rule, but would feel much better if it was >> clearly stated in the "Building libpq Programs" page. > > Agreed. Either that page, or the libpq top page at > http://www.postgresql.org/docs/devel/static/libpq.html, or a new > "cross-version compatibility" section under that. Could you write up a > few paragraphs for the manual please? That would be much appreciated, > you'd be in a good position to do that since you're facing the problem > right now. > > - Heikki >