Re: Confusion over Python drivers

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Confusion over Python drivers
Date: 2010-02-05 23:47:19
Message-ID: e51f66da1002051547o6d518ec0xbed257b7111e2883@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/5/10, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> The issues here have already been identified: the Perl DBI is an excellent
> spec, while the Python one is so weak everybody ends up needing their own
> extensions to it. And then portability *even among Python PostgreSQL
> drivers* goes out the window.

Well, no. You are overplaying on the DBI angle. If the driver can
offer via the minimal DB-API the same features the DBI driver
can offer, then the DBI API is bloated, not the minimal API weak...

Not that DB-API is perfect, a way to toggle prepare and db cursors
on/off in per-query basis would be good to have, but thats mostly it.
Rest of extra features (COPY) need to be done as extensions anyway.

But all that is off-topic to the current driver suckiness.

The problems with Python drivers are that they fail to implement
even the minimal DB-API 2.0:

- correctly, across all interesting data types.
PygreSQL (bytea).
pg8000 (does rollback after query fails - WTF).
None of the drivers seem to support both array and tuple.

- robustly. Psycopg2 - their misguided attempt to turn DB-API
calls optionally async cost their stability big-time as it
complexified their codebase. It got stable around 2.0.[678].
I'm not holding my breath on the other ones.
Fear the fancy API-s.

- with threadsafety level > 1. (I don't care, but seems in some
circles it's necessary.)

Note how many ways a driver can suck without stepping above
basic DB-API 2.0.

> If somebody built a BSD/MIT licensed driver
> that replaces every useful feature of all the forks, with no major problems,
> and a couple of major projects switched over to it (think "Skype" level
> big), maybe this mess could get resolved. I think it would take someone
> already familiar with the major issues involved a couple of months of
> regular work to make any serious progress on it.

Yeah, but the problem here is that there actually is not a problem.
Psycopg license is not bad, just confusing on first
sight. And website problem can be fix by advertising
http://wiki.postgresql.org/wiki/Psycopg as new website...

If your requirement is BSD license, then probably getting PyGreSQL
into shape would be faster than writing from scratch.
Main dev effort would be writing Postgres-specific DB-API 2.0
testsuite anyway. It's likely that actual improvements needed
would be small.

Also I would suggest to match Psycopg extensions API, that would
make it usable to much broader audience. (Eg: PygreSql does
not offer COPY extensions via the DB-API 2.0 API. It would be
good to match Psycopg here, instead inventing new API.)

--
marko

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-02-05 23:55:39 Re: Hot standby documentation
Previous Message Bruce Momjian 2010-02-05 23:27:42 Re: Mammoth in Core?