On 10/01/2013 08:50 PM, Daniel Verite wrote:
> Sebastien FLAESCH wrote:
>
>> 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.
>
> As an example, if your binary calls PQescapeLiteral() and your end user
> has libpq.so.5.1 which ships with PostgreSQL 8.3, then the dynamic link
> will fail because this version of libpq lacks this function.
>
> Not sure if that disqualifies it as backward compatible. It depends
> on your interpretation.
>
> Best regards,
Thank you Daniel,
I understand you point.
In fact we *could* manage to load dynamically (dlopen/dlsym) libpq.so,
(without a specific .5 version number), then lookup for existing PQ*
symbols, and use them only if they exist.
So in the case you describe, if PQescapeLiteral() does not exist, we
would not use it, assuming that the feature is not mandatory or can
be workaround...
But that's only possible if the PostgreSQL client C API header files
are compatible with all versions. I mean, if I compile with PGS 9.3
(to get the latest C structures / API), it must be compatible with older
client libraries. If structures such as PGconn, PGresult are not
compatible, using an older client lib will potentially memory corruption
and invalid/loss of data or crash the program.
This cross-version compatibility must work for existing and future versions.
I am conscious that this is a strong constraint for PostgreSQL.
And I am not ASKING for it:
We are just evaluating this solution.
My instinct is that it's insane to load dynamically a libpq.so, to
be used with a binary that was compiled with C header of a more
recent version.
But without a clear statement in the docs, I have no counter argument.
Note that, Oracle OCI doc states that when your compile with OCI
headers of 10g, your binary will work with 11g and 12c environments,
without the need to recompile / relink.
Here Oracle 11g / 12c is *backward* compatible with 10g...
And Oracle 10g headers are *upward* compatible with future versions.
See 5.5.2.3 and 5.6 of:
http://docs.oracle.com/cd/E16655_01/server.121/e17642/app.htm#i1006731
But in our case we want to compile with recent .h headers (to use
recent features) and use potentially older libs at runtime..
Thanks.
Seb