Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VR316-0004nQ-VU for pgsql-interfaces@arkaria.postgresql.org; Tue, 01 Oct 2013 16:41:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VR316-0004EB-F5 for pgsql-interfaces@arkaria.postgresql.org; Tue, 01 Oct 2013 16:41:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VR16M-0007n0-RH for pgsql-interfaces@postgresql.org; Tue, 01 Oct 2013 14:39:02 +0000 Received: from mail-ee0-f51.google.com ([74.125.83.51]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VR16E-0006Dr-Px for pgsql-interfaces@postgresql.org; Tue, 01 Oct 2013 14:39:01 +0000 Received: by mail-ee0-f51.google.com with SMTP id c1so3457738eek.38 for ; Tue, 01 Oct 2013 07:38:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:reply-to:organization :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=pRwfprbtBJME4oI9zU8WVrkAsiBMpBw1Kos4PojzvsA=; b=AEc4SDuNOUhBDfHLOX8nMHrk71LZ0YPfGR3V/94mGlP9/YYeyytwglrkTV6k7kCCrh LP+WiFbWTqvzNvQ7j8TEZLDpKF8Hx7yq6XLMzKzqadgSs1JSyCsDkDfW8Tf2Gj8prY6r dw0u42KuJPxq1te8bRwsK6hgdsnDMxNjBb/mYxPan6FMdkYDyfwVPLbCV11BcZegmXa2 JMMfFF1rBXFGQz0alXN+0SOg1ugjE/RYgaaVYK3dNVmPjZzjyiIfVN0lfBz7nraNNECW 6xVY1eBav22N57MLGd3lW53zpGbRZt3vO1eICV7cWZHT1or55fsxuENUg4jy6o8PUKOL GFpQ== X-Gm-Message-State: ALoCoQnPm0y8vVFXNMIjRwW7qOIA4FwSsKun7C6CXzqUrbWvkA/CMebRBes+TR2Ru3z0oR4mQFmU X-Received: by 10.14.199.3 with SMTP id w3mr46617128een.33.1380638333149; Tue, 01 Oct 2013 07:38:53 -0700 (PDT) Received: from [192.168.1.102] (135-30-124-91.pool.ukrtel.net. [91.124.30.135]) by mx.google.com with ESMTPSA id h45sm13986801eeg.5.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 01 Oct 2013 07:38:52 -0700 (PDT) Date: Tue, 1 Oct 2013 17:38:51 +0300 From: Pavel Golub Reply-To: Pavel Golub Organization: Microolap X-Priority: 3 (Normal) Message-ID: <807955869.20131001173851@gf.microolap.com> To: Sebastien FLAESCH CC: pgsql-interfaces@postgresql.org Subject: Re: libpq compatibility policy across versions In-Reply-To: <524AC850.7000109@4js.com> References: <522F0B6B.1040006@4js.com> <113082781.20131001152820@gf.microolap.com> <524AC850.7000109@4js.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-interfaces Precedence: bulk Sender: pgsql-interfaces-owner@postgresql.org Hello, Sebastien. You wrote: SF> Thank you Pavel, SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >> Yes, you should use the latest client library. It's compatible with >> all prior versions. SF> Just to be clear: SF> We deliver our product without any PostgreSQL lib included. Well, I prefer to deploy products with the latest lib included. Thus I'm absolutely sure in the environment used. SF> Our product installs beside an existing PostgreSQL install, typically SF> on an application server, where both PostgreSQL client and server are SF> installed in the same directory. That's possible of course, but there are a lot of issues you may face with IMHO SF> Imagine for ex a machine with PostgreSQL 8.3 installed. SF> I am asking how I must compile my source code and how to link, to build SF> my binary, to be sure that it's compatible with PostgreSQL 8.3, and SF> any in fact any existing PostgreSQL versions. SF> Can I for ex, use the V 9.3 headers and library on my dev platform SF> and then deliver this binary for any PostgreSQL version? SF> In other words, is the PostgreSQL client C API backward compatible? I'm not sure it is. SF> Today the lib is stamped with 5 (libpq.so.5), will this never change SF> in future versions? SF> Is there a way to detect dynamically the version of the PostgreSQL server? "SELECT version()" will do the trick using direct SQL. http://www.postgresql.org/docs/9.3/static/functions-info.html PQserverVersion - will help you if you need an integer representing the backend version. http://www.postgresql.org/docs/9.3/static/libpq-status.html SF> Thanks! SF> Seb SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >> Hello, Sebastien. >> >> You wrote: >> >> SF> Hi all, >> >> SF> We have a libpq client application written in C. >> >> SF> We want to deliver the software so that can it be used with different >> SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). >> >> SF> So far, we build (compile and link) a binary with each major version >> SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared >> SF> libraries (database driver) for each PostgreSQL version. >> >> SF> Is this the proper way, or could we just compile/link with a given >> SF> version (9.3) and assume that it's backward compatible with any >> SF> prior version such as 8.3 ? >> >> Yes, you should use the latest client library. It's compatible with >> all prior versions. >> >> SF> Assuming that we could dynamically load the libpq.so client, search >> SF> for existing API symbols and only use them if present? >> >> SF> Is this risky? Do the C headers define C structures that are compatible >> SF> between newer and older versions? >> >> SF> I would expect some note about libpq compatibility policy here: >> >> SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html >> >> SF> I can see that the lib version number of libpq.so.x.y changes >> SF> for each major version: >> >> SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 >> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 >> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 >> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 >> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 >> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 >> >> SF> The binaries are dependent from libpq.so.5: >> >> SF> $ ldd -r dbmpgs92x.so >> SF> ... >> SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) >> SF> ... >> >> SF> What does this mean? >> >> SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version >> SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) >> >> SF> The main question is about C header compatibility: >> >> SF> - Compile + link with PostgreSQL client version X.Y.? >> SF> - What PostgreSQL client version can be used at runtime? >> >> SF> Thanks. >> SF> Seb >> >> >> >> >> -- With best wishes, Pavel mailto:pavel@gf.microolap.com -- Sent via pgsql-interfaces mailing list (pgsql-interfaces@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-interfaces