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