source: trunk/docs/future.rst @ 510

Last change on this file since 510 was 467, checked in by darcy, 7 years ago

Convert docs to sphinx.
Clears ticket #4.
Needs review before changing the home page (ticket #3)

File size: 2.7 KB
Line 
1PyGreSQL future directions
2==========================
3
4This list has been closed since tasks are now managed with the PyGreSQL
5tracker that can be found at http://trac.vex.net:8000/pgtracker.
6(ticket numbers have been added below):
7
8To Do
9-----
10
11- Add docs for the pgdb module (everything specific to PyGreSQL) (#5).
12- The large object and direct access functions need much more attention (#6).
13- The fetch method should use real cursors (#7).
14- The C module needs to be cleaned up and redundant code merged,
15  and should get its own unit test module (#8).
16- Clean up test_pg.py and merge it with TEST_PyGreSQL_classic.py (#9).
17- The test suite for the classic module should also check that quoted
18  mixed-case identifiers can be used everywhere - currently they can't.
19  Improve pg.py accordingly, adding quotes etc. as needed (#10).
20- What shall we do with the "tutorial" directory - it's rather a tutorial
21  for Postgres/SQL than for PyGreSQL, it's using only the query method from
22  the classic pg module and no other PyGreSQL functionality, it's rather
23  a demo than a tutorial (#11)?
24
25Proposed Patches
26----------------
27
28- Notice handling with PQsetNoticeReceiver and PQsetNoticeProcessor
29  (one possible implementation was already suggested by Dmitry Dvoinikov
30  https://mail.vex.net/mailman/private.cgi/pygresql/2005-November/001530.html).
31  Maybe also make notifications accessible via the optional cursor and
32  connection attribute "messages" proposed in the DB-API specs (#12).
33
34Wish List
35---------
36
37- Make SQLSTATE error codes available (#13).
38- Support the new listen/notify infrastructure of PostgreSQL 9.0 (#15).
39- Make use of PQexecParams() and PQprepare(). This could speed up
40  executemany() and allow retrieving binary data directly by setting
41  the resultFormat parameter to one (#16).
42- Enhance cursor.description attribute, delivering more information
43  available with PQfmod() or PQftable() for instance (#17).
44- Support optional "errorhandler" extension (#18).
45- Support optional cursor and connection attribute "messages" (#19).
46- Connection as context manager (see http://tinyurl.com/32bx6xo) (#20).
47- Users should be able to register their own types with _pg (#21).
48- Let pg and pgdb support namedtuples (as available in Py 2.6).
49  pg could get a new method namedresult(), and pgdb could provide
50  a row factory for namedtuples (similar to sqlite3) (#22).
51- New methods in the classic module, similar to getresult() and
52  dictresult(), but returning dictionaries of rows instead of lists
53  of rows (with primary key or oids as keys) (#23).
54- Make PyGreSQL thread-safe on the connection level (#24).
55- The API documentation could be created with Epydoc or Sphinx (#4).
56- Write a tutorial for beginners and advanced use (#11).
57- More and better documented examples (#4, #5, #11).
Note: See TracBrowser for help on using the repository browser.