mirror of https://github.com/postgres/postgres
Update docs for new stored procedure error levels.
This commit is contained in:
parent
7d5edf2ba7
commit
ade0fe5cb4
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$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">
|
||||
|
@ -278,13 +278,12 @@ CREATE FUNCTION badfunc() RETURNS integer AS '
|
|||
<term><function>elog</> <replaceable>level</replaceable>, <replaceable>msg</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Emit a log or error message. Possible levels are <literal>DEBUG</>,
|
||||
<literal>NOTICE</>, and <literal>ERROR</>.
|
||||
<literal>DEBUG</> and <literal>NOTICE</> simply emit the given message
|
||||
into the postmaster log (and send it to the client too, in the case of
|
||||
<literal>NOTICE</>). <literal>ERROR</> raises an error condition:
|
||||
further execution of the function is abandoned, and the current
|
||||
transaction is aborted.
|
||||
Emit a log or error message. Possible levels are
|
||||
<literal>DEBUG</>, <literal>LOG</>, <literal>INFO</>,
|
||||
<literal>NOTICE</>, <literal>WARNING</>, and <literal>ERROR</>.
|
||||
<literal>ERROR</> raises an error condition: further execution
|
||||
of the function is abandoned, and the current transaction is
|
||||
aborted.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $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">
|
||||
<title>PL/Python - Python Procedural Language</title>
|
||||
|
@ -150,12 +150,14 @@ def __plpython_procedure_myfunc_23456():
|
|||
this module are available to you in the Python code as
|
||||
<literal>plpy.<replaceable>foo</replaceable></literal>. At present
|
||||
<literal>plpy</literal> implements the functions
|
||||
<literal>plpy.error("msg")</literal>,
|
||||
<literal>plpy.fatal("msg")</literal>,
|
||||
<literal>plpy.debug("msg")</literal>, and
|
||||
<literal>plpy.notice("msg")</literal>. They are mostly equivalent
|
||||
to calling <literal>elog(<replaceable>LEVEL</>, "msg")</literal>,
|
||||
where <replaceable>LEVEL</> is DEBUG, ERROR, FATAL or NOTICE.
|
||||
<literal>plpy.debug("msg")</literal>,
|
||||
<literal>plpy.log("msg")</literal>,
|
||||
<literal>plpy.info("msg")</literal>,
|
||||
<literal>plpy.notice("msg")</literal>,
|
||||
<literal>plpy.warning("msg")</literal>,
|
||||
<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>
|
||||
actually raise a Python exception which, if uncaught, causes the
|
||||
PL/Python module to call <literal>elog(ERROR, msg)</literal> when
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$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">
|
||||
|
@ -441,16 +441,17 @@ SELECT 'doesn''t' AS ret
|
|||
<term><function>elog</> <replaceable>level</replaceable> <replaceable>msg</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Emit a log or error message. Possible levels are <literal>DEBUG</>,
|
||||
<literal>NOTICE</>, <literal>ERROR</>, and <literal>FATAL</>.
|
||||
<literal>DEBUG</> and <literal>NOTICE</> simply emit the given message
|
||||
into the postmaster log (and send it to the client too, in the case of
|
||||
<literal>NOTICE</>). <literal>ERROR</> raises an error condition:
|
||||
further execution of the function is abandoned, and the current
|
||||
transaction is aborted. <literal>FATAL</> aborts the transaction and
|
||||
causes the current backend to shut down (there is probably no good
|
||||
reason to use this error level in PL/Tcl functions, but it's provided
|
||||
for completeness).
|
||||
Emit a log or error message. Possible levels are
|
||||
<literal>DEBUG</>, <literal>LOG</>, <literal>INFO</>,
|
||||
<literal>NOTICE</>, <literal>WARNING</>, <literal>ERROR</>, and
|
||||
<literal>FATAL</>. Most simply emit the given message just like
|
||||
the <literal>elog</> backend C function. <literal>ERROR</>
|
||||
raises an error condition: further execution of the function is
|
||||
abandoned, and the current transaction is aborted.
|
||||
<literal>FATAL</> aborts the transaction and causes the current
|
||||
backend to shut down (there is probably no good reason to use
|
||||
this error level in PL/Tcl functions, but it's provided for
|
||||
completeness).
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
Loading…
Reference in New Issue