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
>> 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(at)gf(dot)microolap(dot)com