Re: libpq compatibility policy across versions

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

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

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

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

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

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

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

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

Seb

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