# PyGreSQL future directions

# To Do

- Documentation for the pgdb module (everything specific to PyGreSQL).
- The large object and direct access functions need much more attention.
- The C module needs to be cleaned up and redundant code merged, and should get its own unit test module.
- The fetch method should use real cursors.
- What shall we do with the "tutorial" directory (it's rather a tutorial for Postgres/SQL than for PyGreSQL, it's using only the query method from the classic pg module and no other PyGreSQL functionality, it's rather a demo than a tutorial)?

# Proposed Patches

- Notice handling with PQsetNoticeReceiver and PQsetNoticeProcessor (one possible implementation was already suggested by Dmitry Dvoinikov http://mailman.vex.net/pipermail/pygresql/2005-November/001530.html). Maybe also make notifications accessible via the optional cursor and connection attribute "messages" proposed in the DB-API specs.

# Wish List

- Make SQLSTATE error codes available.
- Make use of PQexecParams() and PQprepare(). This could speed up executemany() and allow retrieving binary data directly by setting the resultFormat parameter to one.
- Support optional "errorhandler" extension.
- Support optional cursor and connection attribute "messages".
- Connection as context manager (see http://tinyurl.com/6j9cef).
- Users should be able to register their own types with _pg.
- Let pg and pgdb support namedtuples (as available in Py 2.6). pg could get a new method namedresult(), and pgdb could provide a row factory for namedtuples (similar to sqlite3).
- New methods in the classic module, similar to getresult() and dictresult(), but returning dictionaries of rows instead of lists of rows (with primary key or oids as keys).
- Make PyGreSQL thread-safe on the connection level.
- The API documentation could be created with Epydoc.
- Write a tutorial for beginners and advanced use.
- More and better documented examples.