From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pl/python table functions |
Date: | 2010-12-23 14:00:04 |
Message-ID: | 4D1355E4.2010309@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here's a patch implementing table functions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/table-functions.
This allows functions with multiple OUT parameters returning both one or
multiple records (RECORD or SETOF RECORD). There's one inconvenience,
which is that if you return a record that has fields of composite types,
the I/O functions for these types will be looked up on each execution.
Changing that would require some juggling of the PL/Python structures,
so I just left it at that.
Note that returning just the composite type (or a set of them) does
cache the I/O funcs. You get the repeated lookups only if the function
returns an unnamed record, that has composite field among others, so
something like
CREATE FUNCTION x(OUT x table_type, OUT y integer) RETURNS RECORD
which I think is fairly uncommon.
Cheers,
Jan
Attachment | Content-Type | Size |
---|---|---|
plpython-table-functions.diff | text/x-patch | 30.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kenneth Marshall | 2010-12-23 14:03:00 | Re: Why is sorting on two columns so slower than sorting on one column? |
Previous Message | Jan Urbański | 2010-12-23 13:56:03 | pl/python tracebacks |