psycopg2: connect copy_from and copy_to

[james.pye at gmail.com]

On Feb 20, 9:27 am, Thomas Guettler <h... at tbz-pariv.de> wrote:
> Up to now I am happy with psycopg2.

Yeah. psyco is good.

>  Why do you develop pg_proboscis?

[Good or bad as they may be]

1. Alternate interface ("greentrunk")
2. Non-libpq implementation yields better control over the wire that
allows:
    a. Custom communication channels (not limited to libpq's
worldview)
    b. Leveraging of protocol features that libpq's API does not fully
accommodate (think bulk INSERTs using prepared statements with less
round-trip costs)
    c. Allows custom "sub-protocols"(I use this to implement a remote
python command/console[pdb'ing stored Python procedures, zero network
latency
       scripts]).
3. Makes use of binary types to reduce bandwidth usage. (I started
developing this before libpq had the ability to describe statements to
derive statement
   parameter types and cursor column types(?), so using the binary
format was painful at best)
4. Has potential for being used in event driven applications without
threads.
5. Better control/understanding of running queries allows for
automatic operation interrupts in exception cases:
   [The last two may be possible using libpq's async interfaces, but
I'm not entirely sure]
6. Arguably greater(well, *easier* is likely a better word)
portability. While I have yet to get it to work with other
Pythons(pypy, ironpython, jython), the potential to work with these
alternate implementations is there. The real impediment here is
missing/inconsistent features in the implementations(setuptools
support, missing os module in ironpython(i know, i know, and I don't
care. Last time I checked, it's missing from the default install
that's broken :P), jython is still at 2.2, iirc)
7. Bit of a license zealot. psycopg2 is [L?]GPL, pg_proboscis is
BSD[or MIT if you like] like PostgreSQL. (Yes, Darcy's interface is
BSD licensed(iirc), but it too is libpq based)

In sum, it yields greater control over the connection which I believe
will lead to a more flexible and higher quality interface than a libpq
solution.
[The primary pain point I've had is implementing all the
authentication mechanisms supported by PG]