Commit ade0fe5c authored by Bruce Momjian's avatar Bruce Momjian

Update docs for new stored procedure error levels.

parent 7d5edf2b
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.15 2002/01/25 19:13:15 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.16 2002/03/06 19:05:57 momjian Exp $
--> -->
<chapter id="plperl"> <chapter id="plperl">
...@@ -278,13 +278,12 @@ CREATE FUNCTION badfunc() RETURNS integer AS ' ...@@ -278,13 +278,12 @@ CREATE FUNCTION badfunc() RETURNS integer AS '
<term><function>elog</> <replaceable>level</replaceable>, <replaceable>msg</replaceable></term> <term><function>elog</> <replaceable>level</replaceable>, <replaceable>msg</replaceable></term>
<listitem> <listitem>
<para> <para>
Emit a log or error message. Possible levels are <literal>DEBUG</>, Emit a log or error message. Possible levels are
<literal>NOTICE</>, and <literal>ERROR</>. <literal>DEBUG</>, <literal>LOG</>, <literal>INFO</>,
<literal>DEBUG</> and <literal>NOTICE</> simply emit the given message <literal>NOTICE</>, <literal>WARNING</>, and <literal>ERROR</>.
into the postmaster log (and send it to the client too, in the case of <literal>ERROR</> raises an error condition: further execution
<literal>NOTICE</>). <literal>ERROR</> raises an error condition: of the function is abandoned, and the current transaction is
further execution of the function is abandoned, and the current aborted.
transaction is aborted.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
......
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.8 2002/01/07 02:29:13 petere Exp $ --> <!-- $Header: /cvsroot/pgsql/doc/src/sgml/plpython.sgml,v 1.9 2002/03/06 19:05:57 momjian Exp $ -->
<chapter id="plpython"> <chapter id="plpython">
<title>PL/Python - Python Procedural Language</title> <title>PL/Python - Python Procedural Language</title>
...@@ -150,12 +150,14 @@ def __plpython_procedure_myfunc_23456(): ...@@ -150,12 +150,14 @@ def __plpython_procedure_myfunc_23456():
this module are available to you in the Python code as this module are available to you in the Python code as
<literal>plpy.<replaceable>foo</replaceable></literal>. At present <literal>plpy.<replaceable>foo</replaceable></literal>. At present
<literal>plpy</literal> implements the functions <literal>plpy</literal> implements the functions
<literal>plpy.error("msg")</literal>, <literal>plpy.debug("msg")</literal>,
<literal>plpy.fatal("msg")</literal>, <literal>plpy.log("msg")</literal>,
<literal>plpy.debug("msg")</literal>, and <literal>plpy.info("msg")</literal>,
<literal>plpy.notice("msg")</literal>. They are mostly equivalent <literal>plpy.notice("msg")</literal>,
to calling <literal>elog(<replaceable>LEVEL</>, "msg")</literal>, <literal>plpy.warning("msg")</literal>,
where <replaceable>LEVEL</> is DEBUG, ERROR, FATAL or NOTICE. <literal>plpy.error("msg")</literal>, and
<literal>plpy.fatal("msg")</literal>. They are mostly equivalent
to calling <literal>elog(<replaceable>LEVEL</>, "msg")</literal>.
<function>plpy.error</function> and <function>plpy.fatal</function> <function>plpy.error</function> and <function>plpy.fatal</function>
actually raise a Python exception which, if uncaught, causes the actually raise a Python exception which, if uncaught, causes the
PL/Python module to call <literal>elog(ERROR, msg)</literal> when PL/Python module to call <literal>elog(ERROR, msg)</literal> when
......
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.18 2002/01/23 21:08:17 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v 2.19 2002/03/06 19:05:58 momjian Exp $
--> -->
<chapter id="pltcl"> <chapter id="pltcl">
...@@ -441,16 +441,17 @@ SELECT 'doesn''t' AS ret ...@@ -441,16 +441,17 @@ SELECT 'doesn''t' AS ret
<term><function>elog</> <replaceable>level</replaceable> <replaceable>msg</replaceable></term> <term><function>elog</> <replaceable>level</replaceable> <replaceable>msg</replaceable></term>
<listitem> <listitem>
<para> <para>
Emit a log or error message. Possible levels are <literal>DEBUG</>, Emit a log or error message. Possible levels are
<literal>NOTICE</>, <literal>ERROR</>, and <literal>FATAL</>. <literal>DEBUG</>, <literal>LOG</>, <literal>INFO</>,
<literal>DEBUG</> and <literal>NOTICE</> simply emit the given message <literal>NOTICE</>, <literal>WARNING</>, <literal>ERROR</>, and
into the postmaster log (and send it to the client too, in the case of <literal>FATAL</>. Most simply emit the given message just like
<literal>NOTICE</>). <literal>ERROR</> raises an error condition: the <literal>elog</> backend C function. <literal>ERROR</>
further execution of the function is abandoned, and the current raises an error condition: further execution of the function is
transaction is aborted. <literal>FATAL</> aborts the transaction and abandoned, and the current transaction is aborted.
causes the current backend to shut down (there is probably no good <literal>FATAL</> aborts the transaction and causes the current
reason to use this error level in PL/Tcl functions, but it's provided backend to shut down (there is probably no good reason to use
for completeness). this error level in PL/Tcl functions, but it's provided for
completeness).
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment