Am 07.02.2010 21:17 schrieb Christopher Hilton:
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?
This would be better for the performance of pg, but not of pgdb. Note
that pg is already a thin wrapper around the C lib, with some additions
which are of no interest for pgdb.
A perceived lack of a DB-API2 interface in part driven by PyGreSQL's
lack of documentation of that interface;
Of course the DB-API2 documentation already exists, but we should really
document the differences and additions - particularly which of the
optional parts we implemented, which types are supported and how they
work. A few examples would also not hurt.
A handful of missing features, some of which are present: copy
in/copy out and some of which aren't? bytea
Copy is partially implemented in pg via "inserttable". But we should
also provide copy_from() and copy_to() methods for pgdb cursors. Bytea
is actually supported by pg and pgdb; again it seems the lacking docs
are the only problem here.
Btw, we already have identified a couple of issues on our todo list:
http://www.pygresql.org/future.html
Some developer friendly features like a bug reporting database and
> more modern revision control.
A bug tracker would also allow people to vote for features and make it
easier to submit patches.
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
