On Tue, 2008-11-04 at 14:05 -0500, David Blewett wrote:
> On Sat, Nov 1, 2008 at 7:52 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> > On Sat, 2008-11-01 at 06:13 +0200, Hannu Krosing wrote:
> >> attached is a patch which enables plpython to recognize function with
> >> multiple OUT params as returning a record
> >
> > Overrides previous patch.
> >
> > Fixed some bugs, added regression tests.
>
> Hi Hannu:
>
> I was wondering if it would be possible to get plpython to convert IN
> parameters of type ARRAY to Python lists? I see some example functions
> here [1], but it would be nice if it was done automatically.
This is one thing I definitely will do, praobably right after getting
ANY* to work, maybe even before, if getting ANY* to work requires too
many changes.
One open question is how to translate arrays with non-default subscript
values
Quote: "Subscripted assignment allows creation of arrays that do not use
one-based subscripts. For example one might assign to myarray[-2:7] to
create an array with subscript values running from -2 to 7."
Should I just shift it to standard python tuple, or would it be better
to return it as a dictionary with keys from -2 to 7
sample:
hannu=# create table ta(ia int[]);
CREATE TABLE
hannu=# insert into ta values('{27000,27000}');
INSERT 0 1
hannu=# update ta set ia[-2:1] = '{-2,-1,0,1}';
UPDATE 1
hannu=# select * from ta;
ia
--------------------------
[-2:2]={-2,-1,0,1,27000}
(1 row)
and if I do return a dictionary , the after this
hannu=# update ta set ia[7:7] = '{7}';
UPDATE 1
hannu=# select * from ta;
ia
------------------------------------------------
[-2:7]={-2,-1,0,1,27000,NULL,NULL,NULL,NULL,7}
(1 row)
should the returned python dict have keys 3-6 with None, or could they
just be omitted ?
Actually I have quite long todo list (attached) of what I'd like to do
with pl/python, but I'm not sure how much will be accepted in 8.4 under
current commitfest/feature freeze scheme.
Anyway, I should put that up on wiki for comments.
> David
>
> 1. http://archives.postgresql.org/pgsql-general/2007-01/msg01417.php
>
--
------------------------------------------
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
