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

Hi Psycopg --

I'm researching putting together a binary distribution of my software, which includes psycopg2. When psycopg2 compiles,
itlinks to postgresql. If I linked to PostgreSQL 9.3.3 when I built psycopg2 on my systems, which version(s) of
PosgreSQLare compatible on other user's systems? Or should I just expect other users to build psycopg2 on their own
system?

Thanks!
Amos.

On 09/27/2014 11:24 AM, Amos Anderson wrote:
> Hi Psycopg --
>
> I'm researching putting together a binary distribution of my software, which includes psycopg2. When psycopg2
compiles,it links to postgresql. If I linked to PostgreSQL 9.3.3 when I built psycopg2 on my systems, which version(s)
ofPosgreSQL are compatible on other user's systems? Or should I just expect other users to build psycopg2 on their own
system?

http://initd.org/psycopg/docs/install.html#install-from-source

Note

The libpq header files used to compile psycopg2 should match the version
of the library linked at runtime. If you get errors about missing or
mismatching libraries when importing psycopg2 check (e.g. using ldd) if
the module psycopg2/_psycopg.so is linked to the right libpq.so.


>
> Thanks!
> Amos.
>


--
Adrian Klaver
adrian.klaver@aklaver.com

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.

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


> Thanks!
> Amos.
>

--
Adrian Klaver
adrian.klaver@aklaver.com

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