Improve support for composite types in PL/Python.

Allow PL/Python functions to return arrays of composite types.
Also, fix the restriction that plpy.prepare/plpy.execute couldn't
handle query parameters or result columns of composite types.

In passing, adopt a saner arrangement for where to release the
tupledesc reference counts acquired via lookup_rowtype_tupdesc.
The callers of PLyObject_ToCompositeDatum were doing the lookups,
but then the releases happened somewhere down inside subroutines
of PLyObject_ToCompositeDatum, which is bizarre and bug-prone.
Instead release in the same function that acquires the refcount.

Ed Behn and Ronan Dunklau, reviewed by Abhijit Menon-Sen

1 files changed, 0 insertions, 7 deletions

diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index 3f0e6290bb2..e209b2a2d23 100644
--- a/doc/src/sgml/plpython.sgml
+++ b/doc/src/sgml/plpython.sgml
@@ -1026,13 +1026,6 @@ rv = plpy.execute(plan, ["name"], 5)
      <para>
       Query parameters and result row fields are converted between PostgreSQL
       and Python data types as described in <xref linkend="plpython-data">.
-      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.
      </para>
 
      <para>