Friday, May 7, 2010

Update: PostgreSQL doesn't really need a new Python driver

A couple of months ago, there was a brief stir in the PostgreSQL community about the state of the Python drivers and there being too many of them. While we can't really do much anymore about there being too many, the most popular driver, Psycopg, has since had a revival:
  • A new release 2.0.14 has been issued.
  • The license has been changed to GNU LGPL 3, alleviating various concerns about the previous "hacked up" license.
Of course, this doesn't yet fix every single bug that has been mentioned, but it ought to be the foundation for a viable future. The mailing list has been quite active lately, and the Git repository has seen a bunch of commits, by multiple developers. So if you have had issues with Psycopg, get involved now. And thanks to all who have made this "revival" happen.

1 comment:

  1. Hello Peter,

    thank you very much for the acknowledgement, it's a good thing for everybody that a costly and traumatic investment such as a new driver is not needed.

    I would like to know what are the "bug mentioned" that have not been fixed yet: quoting Josh's post:

    """
    Psycopg2 is the most popular driver. However, it's (A) under a bizarre hacked-up license, and (B) the website for it has been unmaintained for the last couple years (even if the driver is still being updated and improved). Further, Psycopg has a number of issues resulting from trying to do too much, such as (C) asynch code problems, (D) transaction control (at least with Django) (E) and using its own escaping instead of libpq's. (Drivers who do too much and the developers that love them -- 10pm, Lifetime)
    """

    So, (A) and (B) have been fixed. (C) is under deep revamping (with a lot of activity in the last two months in the ML and the contribution of at least three hackers) and scheduled for release in the upcoming release, but is really a specialized area that shouldn't be a concern for people using the driver with the regular DBAPI semantics. (E) was a point overlooked by Josh (psycopg is long using PQescapeStringConn).

    About (D) I haven't honestly seen a proper report, and I've googled hard for it: if somebody showed us a failing case we'd be happy to address it. The only people I've spoken with, which were reporting problems related to psycopg messing up with transactions, were actually doing something wrong at a different level, e.g. with Django transactions.

    As LWN has outlined (http://lwn.net/Articles/374627/) it's been the lack of communication, more than technical weakness or political divergences, that has created much of the fuss: if there is any concern about psycopg, please report it to the mailing list and it will be definitely addressed.

    Cheers!

    ReplyDelete