| 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: | [email protected] |
| Views: | Whole Thread | Raw Message | 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 |