Date: Sun, 31 Jan 2010 13:20:25 +0100
From: Steve White <swhite@aip.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-bugs@postgresql.org
Subject: Re: BUG #5272: PL/Python SELECT: return composite fields as dict,
	not str
Message-ID: <20100131122025.GA9797@cashmere.aip.de>
References: <201001111641.o0BGf7cw063967@wwwmaster.postgresql.org>
	<603c8f071001111831j5b05b57cs108d2792c390e26@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <603c8f071001111831j5b05b57cs108d2792c390e26@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
"Organization: Astrophysikalisches Institut Potsdam"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5
	tests=BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 201001/281
X-Sequence-Number: 25785


--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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 <swhite@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
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="plpython.sgml.diff"

--- 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 -->
 

--mYCpIKhGyMATD0i+--