On Feb 7, 2010, at 10:51 AM, Christoph Zwerschke wrote:
> Am 07.02.2010 15:43 schrieb D'Arcy J.M. Cain:
>
>> Does one ot the other need to be the focus? One thing that I have
>> wanted to do for a while is make the classic interface a pure Python
>> wrapper around the DB-API. That way it can be used with any database
>> and not just PostgreSQL. If we do that we might want to make the
>> classic interface a separate project.
>
> Sounds good, but the classic API als has some low level features which are
> Postgres specific (large objects, bytea, oid etc.) and/or
> difficult/impossible to implement based on a pure DB-API2.
>
Normally I lurk on this list but I read this topic and the thread in the
postgresql list with some interest. At the risk of exposing my ignorance. May I
add my thoughts?
Would it not be better for performance to leave the classic (import pg)
interface as a wrapper around the C library and have the DB-API2 interface as a
wrapper around classic? E.g. doesn't the object oriented nature of the DB-API2
interface make it more easier to build extensions like copy in/copy out in a
way that's most portable for developers?
>> I know that I have resisted SVN in the past. I am coming around
>> though. If I switch I can run it here. I already have an SVN
>> repository for other projects.
>
> That would be great. It will also make the project more attractive for other
> developers. Maybe you can also install a Trac instance if you don't want to
> host it at SF or Google where they already have trackers.
>
After reading the original thread it really looks to me like the postgresql
developers are looking to bless one DB-API2 compliant interface as the "one
true" path from python to postgresql. From a features perspective they would
like to do this with psycopg2 but they really don't like the current state of
that project's organization and they don't like it's use of a GPL style
license. If they can't get what they want from psycopg2 they would bless us
instead but for:
A perceived lack of a DB-API2 interface in part driven by PyGreSQL's lack
of documentation of that interface;
A handful of missing features, some of which are present: copy in/copy out
and some of which aren't? bytea
Some developer friendly features like a bug reporting database and more
modern revision control.
So, is this really a case of needing to get the PyGreSQL documentation and
developer tools in better order?
-- Chris Hilton
> -- Chris
> _______________________________________________
> PyGreSQL mailing list
> [email protected]
> http://mailman.vex.net/mailman/listinfo/pygresql
>
----------------------------------------------------------------------------
"There will be an answer, Let it be."
e: chris -at- vindaloo -dot- com
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
