1- <!-- $PostgreSQL: pgsql/doc/src/sgml/plpython.sgml,v 1.24 2004/09/13 20:05:18 tgl Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/plpython.sgml,v 1.25 2004/12/17 02:14:44 tgl Exp $ -->
22
33<chapter id="plpython">
44 <title>PL/Python - Python Procedural Language</title>
4646 <title>PL/Python Functions</title>
4747
4848 <para>
49- The Python code you write gets transformed into a Python function. E.g.,
49+ The Python code you write gets transformed into a Python function.
50+ For example,
5051<programlisting>
5152CREATE FUNCTION myfunc(text) RETURNS text
5253 AS 'return args[0]'
@@ -60,13 +61,14 @@ def __plpython_procedure_myfunc_23456():
6061 return args[0]
6162</programlisting>
6263
63- assuming that 23456 is the OID of the function.
64+ assuming that 23456 is the OID assigned to the function by
65+ <productname>PostgreSQL</productname>.
6466 </para>
6567
6668 <para>
6769 If you do not provide a return value, Python returns the default
68- <symbol>None</symbol>.The language module translates Python's
69- <symbol>None</symbol> into the SQL null
70+ <symbol>None</symbol>.<application>PL/Python</application> translates
71+ Python's <symbol>None</symbol> into the SQL null
7072 value.<indexterm><primary>null value</><secondary
7173 sortas="PL/Python">in PL/Python</></indexterm>
7274 </para>
@@ -108,7 +110,7 @@ def __plpython_procedure_myfunc_23456():
108110 </indexterm>
109111
110112 <para>
111- When a function is usedin a trigger, the dictionary
113+ When a function is usedas a trigger, the dictionary
112114 <literal>TD</literal> contains trigger-related values. The trigger
113115 rows are in <literal>TD["new"]</> and/or <literal>TD["old"]</>
114116 depending on the trigger event. <literal>TD["event"]</> contains
@@ -120,9 +122,9 @@ def __plpython_procedure_myfunc_23456():
120122 <literal>STATEMENT</>, and <literal>UNKNOWN</>.
121123 <literal>TD["name"]</> contains the trigger name, and
122124 <literal>TD["relid"]</> contains the OID of the table on
123- which the trigger occurred. If thetrigger was called with
124- arguments they are available in <literal>TD["args"][0]</> to
125- <literal>TD["args"][(n -1)]</>.
125+ which the trigger occurred. If the<command>CREATE TRIGGER</> command
126+ included arguments, they are available in <literal>TD["args"][0]</> to
127+ <literal>TD["args"][(<replaceable>n</> -1)]</>.
126128 </para>
127129
128130 <para>
@@ -143,23 +145,23 @@ def __plpython_procedure_myfunc_23456():
143145 this module are available to you in the Python code as
144146 <literal>plpy.<replaceable>foo</replaceable></literal>. At present
145147 <literal>plpy</literal> implements the functions
146- <literal>plpy.debug("msg")</literal>,
147- <literal>plpy.log("msg")</literal>,
148- <literal>plpy.info("msg")</literal>,
149- <literal>plpy.notice("msg")</literal>,
150- <literal>plpy.warning("msg")</literal>,
151- <literal>plpy.error("msg")</literal>, and
152- <literal>plpy.fatal("msg")</literal>. They are mostly equivalent
153- to calling <literal>elog(<replaceable>LEVEL</>, "msg")</literal>
148+ <literal>plpy.debug(<replaceable>msg</>)</literal>,
149+ <literal>plpy.log(<replaceable>msg</>)</literal>,
150+ <literal>plpy.info(<replaceable>msg</>)</literal>,
151+ <literal>plpy.notice(<replaceable>msg</>)</literal>,
152+ <literal>plpy.warning(<replaceable>msg</>)</literal>,
153+ <literal>plpy.error(<replaceable>msg</>)</literal>, and
154+ <literal>plpy.fatal(<replaceable>msg</>)</literal>.
155+ These are mostly equivalent to calling
156+ <literal>elog(<replaceable>level</>, <replaceable>msg</>)</literal>
154157 from C code.<indexterm><primary>elog</><secondary>in
155158 PL/Python</></indexterm> <function>plpy.error</function> and
156159 <function>plpy.fatal</function> actually raise a Python exception
157160 which, if uncaught, causes the PL/Python module to call
158161 <literal>elog(ERROR, msg)</literal> when the function handler
159- returns from the Python interpreter. Long-jumping out of the
160- Python interpreter is probably not good. <literal>raise
161- plpy.ERROR("msg")</literal> and <literal>raise
162- plpy.FATAL("msg")</literal> are equivalent to calling
162+ returns from the Python interpreter. <literal>raise
163+ plpy.ERROR(<replaceable>msg</>)</literal> and <literal>raise
164+ plpy.FATAL(<replaceable>msg</>)</literal> are equivalent to calling
163165 <function>plpy.error</function> and
164166 <function>plpy.fatal</function>, respectively.
165167 </para>
@@ -210,17 +212,6 @@ rv = plpy.execute(plan, [ "name" ], 5)
210212 The third argument is the limit and is optional.
211213 </para>
212214
213- <para>
214- In the current version, any database error encountered while
215- running a <application>PL/Python</application> function will result
216- in the immediate termination of that function by the server; it is
217- not possible to trap error conditions using Python <literal>try
218- ... catch</literal> constructs. For example, a syntax error in an
219- SQL statement passed to the <literal>plpy.execute</literal> call
220- will terminate the function. This behavior may be changed in a
221- future release.
222- </para>
223-
224215 <para>
225216 When you prepare a plan using the PL/Python module it is
226217 automatically saved. Read the SPI documentation (<xref