Hi all,

Robert suggested that I start some documentation about limitations of 
PL/Python.  Find attached.

I think it would also be good to explain the meaning of "trusted" regarding
PL/Python, and how it might impact the user.  There is already some
commented-out doc, and also something in the PL/Perl section. 
Specifically, a user might want to know if it is actually dangerous to
use PL/Python, etc.  If it is dangerous, how, and for whom?  Where should
one be careful?

Cheers!

On 11.01.10, Robert Haas wrote:
> On Mon, Jan 11, 2010 at 11:41 AM, Steve White <swh...@aip.de> wrote:
> > I see nothing in the documentation about this
> >        http://www.postgresql.org/docs/8.4/static/plpython.html
> > It only talks about passing composite types into and out of functions.
> >
> > This is an unpleasant discovery for those working to a deadline.  Perhaps a
> > "limitations" section for the doc would be in order.  (You could also list
> > the limitations of PL/Python regarding returning RECORD types.)
> 
> Maybe you could suggest some text, perhaps in the form of a context
> diff against the current sgml files?
> 

-- 
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
| Steve White                                             +49(331)7499-202
| e-Science / AstroGrid-D                                   Zi. 35  Bg. 20
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
| Astrophysikalisches Institut Potsdam (AIP)
| An der Sternwarte 16, D-14482 Potsdam
|
| Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz
|
| Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
--- plpython.sgml       2009-12-19 23:23:21.000000000 +0100
+++ plpython-new.sgml   2010-01-31 13:17:20.000000000 +0100
@@ -693,6 +693,41 @@
   </para>
  </sect1>
 
+ <sect1 id="plpython-database">
+  <title>Limitations and Work-arounds</title>
+
+   <itemizedlist>
+    <listitem>
+    <para>
+    The result of <function>execute()</function> on a <command>SELECT</command>
+    is a list of dictionary-like objects whose values corresponding to simple
+    database types are of the corresponding Python type.  Unfortunately
+    however, values corresponding to composite types are returned as string
+    representations of the composite value.
+    That is, <application>PL/Python</application> flattens all composite type
+    values to strings.
+    </para>
+    <para>
+    Work-arounds: (1) Do a <command>SELECT</command> whose result is the
+    values of the composite entry. (2) Parse up the result strings.
+    </para>
+    </listitem>
+
+    <listitem>
+    <para>
+    <application>PL/Python</application> functions cannot return either type
+    <type>RECORD</type> or <type>SETOF RECORD</type>.
+    </para>
+    <para>
+    One work-around is to write a <application>PL/pgSQL</application> function
+    that creates a temporary table, have it call the
+    <application>PL/Python</application> function to fill the table,
+    then have function <application>PL/pgSQL</application> function return the
+    generic <type>RECORD</type> from the temporary table.
+    </para>
+    </listitem>
+   </itemizedlist>
+ </sect1>
 <![IGNORE[
  <!-- NOT CURRENTLY SUPPORTED -->
 
-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to