Re: libpq compatibility policy across versions

Hello, Sebastien.

You wrote:

SF> Thank you Pavel, I appreciate your help, but I would however prefer a clear
SF> statement from the PostgreSQL C API developpers, written in the doc... ;-)

Fare enough. :)

SF> We have a commercial software: not sure we can deliver the PostgreSQL client
SF> library in our packages, regarding open source license policy. We don't want
SF> to make the sources of our product public.

We have commercial software too. And we ship it with client library.
It's all OK woth license.

SF> Further, I don't like to ship other software libs in our product, typically
SF> you want to use what is installed on the system.

SF> If there is a bug in the PostgreSQL client lib, it's up to the user to install
SF> the new lib that fixes the bug, without asking us to rebuild a package with
SF> the new pgs lib.

SF> Nothing new here, just traditional shared lib usage and dependency.

SF> Yes, my instinct is also to use the C headers matching the lib version used
SF> at runtime, we do this for now...
SF> But some people think it's possible to provide a unique binary for all versions
SF> of PostgreSQL, so I ask for a clear rule for the PostgreSQL C API.

SF> Note also that we want to use the latest version, to get the latest features
SF> with new C structures and defines...

SF> So typically, we would compile with PostgreSQL 9.3 headers...

SF> Seb

SF> On 10/01/2013 04:38 PM, Pavel Golub wrote:
>> 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