Add some documentation about PL/Python limitations

suggested by Steve White (bug #5272)

diff --git a/doc/src/sgml/plpython.sgml b/doc/src/sgml/plpython.sgml
index 73013840a555a58cf9a8f2ee5fb81dc98da190b2..ab9ad2228af95fc42ed3fe7b4ca6353c71787d9e 100644 (file)
--- 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;
   
  
 
- 
+  id="plpython-data">
   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 (