1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
==========================
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.
|
