Re: libpq compatibility policy across versions

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