Re: Psycopg2 built on local system, ok when distributed?

On Sun, Sep 28, 2014 at 10:49 PM, Adrian Klaver
<adrian.klaver@aklaver.com> wrote:
> On 09/28/2014 02:20 PM, Amos Anderson wrote:
>>
>> Hi Adrian --
>>
>> To confirm, I'm interested in which version(s) of libpq are compatible
>> with a particular _psycopg.so. According to this page:
>> http://www.postgresql.org/support/versioning/
>> PostgreSQL version X.Y.Z says that changing "X.Y" is a major release,
>> while changing "Z" is a minor release. So should I be safe to use a
>> particular _psycopg.so with different minor releases within the same
>> major release? Another option I suppose would be to bundle libpq with my
>> binary distribution since (as Daniele PM'd me) I can connect to any
>> PostgreSQL server.

PM'd by mistake, just pointing out at the box on the top of the same
page Adrian linked:

"""
psycopg2 usually depends at runtime on the libpq dynamic library.
However it can connect to PostgreSQL servers of any supported version,
independently of the version of the libpq used: just install the most
recent libpq version or the most practical, without trying to match it
to the version of the PostgreSQL server you will have to connect to.
"""


> Here is a good thread that explains it better than I could:
>
> http://postgresql.1045698.n5.nabble.com/Details-about-libpq-cross-version-compatibility-td5723830.html
>
> The take away is the second post:
>
> "If your binary is just a client application that uses libpq to speak to
> the server, you can use any (supported) version of libpq with any
> (supported) server version. There hasn't been any incompatible protocol
> changes since version 7.4, which introduced the protocol version 3, and
> even that was done in a backwards-compatible fashion so that even 9.2
> server still supports the old version 2 of the protocol.
>
> Now, another question is what happens if you compile your binaries
> against e.g 9.1 version of libpq, but at runtime, you have 9.2 libpq
> installed. I think that should work too, but not vice versa, if you use
> any new functions from the 9.2 libpq library. In general, you should
> have the same or higher version of libpq at runtime that the binaries
> were built with.
> ... "

It is even broader that this: if there are new functions in libpq 9.2
but psycopg doesn't use them you can still dynamically link with
previous library versions even if at compile time you compiled it with
9.2.

In this respect, psycopg up to 2.5.x only uses functions that are
available in any version from libpq 8.3 on (the only function that was
not available before is lo_truncate: see faq
http://initd.org/psycopg/docs/faq.html#faq-lo-truncate). So compliling
and shipping any supported libpq version (> 9.0) makes no difference.

In psycopg 2.6 things could be restricted a bit: there is a branch due
to be merged in 2.6 to use the new large objects 64 bits api, to
access large objects larger than 2GB, available from postgres 9.3.
Psycopg can still be built with older libpq functions, in which case
the lo64 support won't be available (e.g. seeking past 2GB will just
raise a runtime error). If it is built against libpq 9.3 the lo64
support will be built, so libpq at least 9.3 must be available at
runtime too, otherwise there will be an ImportError.

(the branch is available at
https://github.com/psycopg/psycopg2/tree/lo64 if anybody is
interested).

-- Daniele