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