==========================
PyGreSQL future directions
==========================


To Do
-----

- Support PQescapeStringConn and PQescapeByteaConn
  (see also http://www.postgresql.org/docs/techdocs.49)
- Use PQescapeStringConn in the _quote() function of pg and pgdb.
- Support composite primary keys
  (see http://mailman.vex.net/pipermail/pygresql/2006-May/001688.html)
- The DB-API module needs docstrings and external documentation.
- Create separate unit tests for _pg, pg and pgdb.
- The large object and direct access functions need much more attention.
- An update query should return the number of rows affected.
- The C module needs to be cleaned up and redundant code merged.
- The fetch method should use real cursors.


Proposed Patches
----------------

- Notice handling
  (http://mailman.vex.net/pipermail/pygresql/2005-November/001530.html)


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.
- Users should be able to register their own types with _pg.
- I would like a new method that returns a dictionary
  of dictionaries from a SELECT.
- Add support for persistent and pooled connections
  that can be used in multi-threaded environments (we could simply
  (add http://www.webwareforpython.org/DBUtils to the distribution).
- 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.