/usr/share/doc/python-pygresql/future.html is in python-pygresql 1:4.0-3build1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 | <?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>PyGreSQL future directions</title>
<link rel="stylesheet" href="docs.css" type="text/css" />
</head>
<body>
<div class="document" id="pygresql-future-directions">
<h1 class="title">PyGreSQL future directions</h1>
<div class="section">
<h1><a id="to-do" name="to-do">To Do</a></h1>
<ul class="simple">
<li>Documentation for the pgdb module (everything specific to PyGreSQL).</li>
<li>The large object and direct access functions need much more attention.</li>
<li>The C module needs to be cleaned up and redundant code merged,
and should get its own unit test module.</li>
<li>The fetch method should use real cursors.</li>
<li>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)?</li>
</ul>
</div>
<div class="section">
<h1><a id="proposed-patches" name="proposed-patches">Proposed Patches</a></h1>
<ul class="simple">
<li>Notice handling with PQsetNoticeReceiver and PQsetNoticeProcessor
(one possible implementation was already suggested by Dmitry Dvoinikov
<a class="reference" href="http://mailman.vex.net/pipermail/pygresql/2005-November/001530.html">http://mailman.vex.net/pipermail/pygresql/2005-November/001530.html</a>).
Maybe also make notifications accessible via the optional cursor and
connection attribute "messages" proposed in the DB-API specs.</li>
</ul>
</div>
<div class="section">
<h1><a id="wish-list" name="wish-list">Wish List</a></h1>
<ul class="simple">
<li>Make SQLSTATE error codes available.</li>
<li>Make use of PQexecParams() and PQprepare(). This could speed up
executemany() and allow retrieving binary data directly by setting
the resultFormat parameter to one.</li>
<li>Support optional "errorhandler" extension.</li>
<li>Support optional cursor and connection attribute "messages".</li>
<li>Connection as context manager (see <a class="reference" href="http://tinyurl.com/6j9cef">http://tinyurl.com/6j9cef</a>).</li>
<li>Users should be able to register their own types with _pg.</li>
<li>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).</li>
<li>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).</li>
<li>Make PyGreSQL thread-safe on the connection level.</li>
<li>The API documentation could be created with Epydoc.</li>
<li>Write a tutorial for beginners and advanced use.</li>
<li>More and better documented examples.</li>
</ul>
</div>
</div>
</body>
</html>
|