File: TODO

package info (click to toggle)
python-pgsql 2.4.0-5sarge1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 984 kB
  • ctags: 1,291
  • sloc: ansic: 5,913; python: 4,334; sh: 73; makefile: 71
file content (80 lines) | stat: -rwxr-xr-x 2,637 bytes parent folder | download
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
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
TODO list for pyPgSQL
=====================
ident "@(#) $Id: TODO,v 1.5 2002/12/09 13:45:53 ghaering Exp $"

DATA TYPES
==========

* Unicode support - Evaluate adding automatic encoding conversion. (gh)

* support for all standard PostgreSQL data types (point, line, box, etc.) 
  [This could be placed into pyPgSQL 2.x later]

* An easy to use method (api hook) for adding support for user defined types.

* Investigate trimming down the TypeCache class - why does it need to be able
  to typecast PostgreSQL types? Isn't it enough to just convert from string to
  PostgreSQL data type?

* Implement an arbitrary precision type for Python by wrapping MAPM
  (http://www.tc.umn.edu/~ringx004/mapm-main.html). Then customize the type to
  behave like a PostgreSQL NUMERIC (gh)

* Don't use floats in PgMoney. Make PgMoney a subclass of PgNumeric instead.

* Develop test cases for reading and writing all data types from/to PostgreSQL.

PERFORMANCE
===========

* profiling, to find out which parts are worth optimizing in Python or
  rewriting in C

* performance optimization of typecasts (archictecture changes)

	o long term way (v3): do all typecasting for the retrieved rows at
	once. Remember the order of typecasters to apply (see below)
	
	o short term way to improve performance: add a method getTypeCasters()
	to TypeCache. This gets cursor.description as an attribute and returns
	a list of typecasting callables. We'll have to do constructs similar to
	"casters.append(lambda x: x or None and PgInt8)" to do so. A simplistic
	benchmark shows that this can cut time a __fetchOneRow takes to 50 %

* Investigate ways to improve the performance of PgResultSets (rewrite in C
  and/or possible adaptation of Python Database Row Module from
  http://opensource.theopalgroup.com/)


SOURCE CODE
===========

DOCUMENTATION
=============

* user's guide, using OpenOffice, adapting from Redhat Database
  Documentation (I've got the ok from its author)

BUILDING
========

MISC
====

* Make all classes in pyPgSQL/libpq new style classes.

* move certain settings from module-level to connection level
  (fetchReturnsList, noPostgresCursor)

* Make PgResultSet(ConcreteClass) pickleable. This will probably involve using
  the copy_reg module.

* Make pyPgSQL compatible with PostgreSQL 7.3 (Beta). Make the testcases
  compatible with PostgreSQL 7.2 and 7.3. This requires special-casing the
  access to the system catalogs for the various backend versions.


Developers who have claimed items are:
--------------------------------------
* bga is Billy G. Allie <bill.allie@mug.org>
* gh is Gerhard Hring <gerhard.haering@gmx.de>