diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml index 73013840a5..ab9ad2228a 100644 --- a/doc/src/sgml/plpython.sgml +++ b/doc/src/sgml/plpython.sgml @@ -1,4 +1,4 @@ - + PL/Python - Python Procedural Language @@ -243,7 +243,7 @@ $$ LANGUAGE plpythonu; - + Data Values Generally speaking, the aim of PL/Python is to provide @@ -364,6 +364,18 @@ $$ LANGUAGE plpythonu; return type and the Python data type of the actual return object are not flagged; the value will be converted in any case. + + + + PL/Python functions cannot return + either type RECORD or SETOF RECORD. A + workaround is to write a PL/pgSQL + function that creates a temporary table, have it call the + PL/Python function to fill the table, + and then have the PL/pgSQL function + return the generic RECORD from the temporary table. + + @@ -866,6 +878,20 @@ rv = plpy.execute(plan, [ "name" ], 5) The third argument is the limit and is optional. + + Query parameters and result row fields are converted between + PostgreSQL and Python data types as described + in . The exception is that composite + types are currently not supported: They will be rejected as query + parameters and are converted to strings when appearing in a query + result. As a workaround for the latter problem, the query can + sometimes be rewritten so that the composite type result appears as + a result row rather than as a field of the result row. + Alternatively, the resulting string could be parsed apart by hand, + but this approach is not recommended because it is not + future-proof. + + When you prepare a plan using the PL/Python module it is automatically saved. Read the SPI documentation (