Re: libpq compatibility policy across versions

Thank you Pavel,

On 10/01/2013 02:28 PM, Pavel Golub wrote:> Yes, you should use the latest client library. It's compatible with> all
priorversions.
 

Just to be clear:

We deliver our product without any PostgreSQL lib included.

Our product installs beside an existing PostgreSQL install, typically
on an application server, where both PostgreSQL client and server are
installed in the same directory.

Imagine for ex a machine with PostgreSQL 8.3 installed.

I am asking how I must compile my source code and how to link, to build
my binary, to be sure that it's compatible with PostgreSQL 8.3, and
any in fact any existing PostgreSQL versions.

Can I for ex, use the V 9.3 headers and library on my dev platform
and then deliver this binary for any PostgreSQL version?

In other words, is the PostgreSQL client C API backward compatible?

Today the lib is stamped with 5 (libpq.so.5), will this never change
in future versions?

Is there a way to detect dynamically the version of the PostgreSQL server?

Thanks!
Seb


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