From 8b6010b8350a1756cd85595705971df81b5ffc07 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 3 Jul 2014 16:10:50 -0400 Subject: 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 --- doc/src/sgml/plpython.sgml | 7 ------- 1 file changed, 7 deletions(-) (limited to 'doc/src') 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) 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. -- cgit v1.2.3