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
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? |