plpython

  * refactor code,
    * make maximal use of "funcapi.h" 
    * split out to seperate files
	  * trigger, 
	  * conversions, 
	  * spi, 
	  * python objects, ...
  * pass function arguments as locals
  * add support for types Decimal and datetime, date, time, bool
  * add special handling for bytea, as standard conversion through string representation does not work because python and postgreSQL escapes don't match
  * add support for ARRAY types
  * add support for polymorphic types (ANY, ANYARRAY)
  * add suppoort for input type RECORD (and maybe output too ?)
  * ? add support for any postgresql datatype ( lift code from pl/py ?? ) using postgreSQL's internal ops/funcs
  * add support for transactions, db procedures. test that it is called "directly", then run outside trx
  * add support for modules inside db, either
    * using not yet present PACKAGE mechanism
	* as functions returning type plpython_module
	* as a special relation ( pg_modules ) + functions for inserting/updating/deleting these
  * use pg_proc.probin for storing compiled code
  * add VALIDATOR support ( http://www.postgresql.org/docs/8.3/interactive/xplang-install.html )
  * add trusted language using zope3 RestrictedPython
    * maybe special/direct support for inline SQL using parser from RestrictedPython
  * enable access to stdin/stdout, for COPY FROM/TO like functionality
  * add DEBUGGER support
  * add support for module level stuff
  * add module cjson for JSON support on input and output


  SPI interface:

  * add direct function calls
  * SPI: add iterator support for query() result
  * SPI: add with: support for WHERE CURRENT OF
  * add with: support for subtransactions
    * alternatively add ability to do try: except: with subtransactions
  * support for automatically storing SPI plans


postgreSQL core

  1. add support for pull (streaming) to functions
  2. add support for defining query tree nodes / node-returning-functions or NRFs
  3. re-enable SELECT rules, so that selects can be remoted more intelligently using views, probably variant of 2.

?? mixed access to objects , super duck typing
 1. try sequence
 2. try dict
 3. try attribute


ideas from http://www.postgresql.org/docs/faqs.TODO.html

Other

    * Add capability to create and call PROCEDURES
    * Add PL/PythonU tracebacks
      http://archives.postgresql.org/pgsql-patches/2006-02/msg00288.php
    * Allow data to be passed in native language formats, rather than only text
      http://archives.postgresql.org/pgsql-hackers/2007-05/msg00289.php

...

PL/pgSQL functions can also be declared to accept and return the polymorphic 
types ANYELEMENT, ANYARRAY, ANYNONARRAY, and ANYENUM. The actual data types 
handled by a polymorphic function can vary from call to call, as discussed 
in Section 34.2.5. An example is shown in Section 38.3.1.