Home Explore Blog CI



postgresql

15th chunk of `doc/src/sgml/plpython.sgml`
fd85e8bca8729e623be11d45e8b5d5ae178f557e863ef47b0000000100000b32
 <member><literal>plpy.error(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.fatal(<replaceable>msg, **kwargs</replaceable>)</literal></member>
   </simplelist>
   <indexterm><primary>elog</primary><secondary>in PL/Python</secondary></indexterm>
   <function>plpy.error</function> and <function>plpy.fatal</function>
   actually raise a Python exception which, if uncaught, propagates out to
   the calling query, causing the current transaction or subtransaction to
   be aborted.  <literal>raise plpy.Error(<replaceable>msg</replaceable>)</literal> and
   <literal>raise plpy.Fatal(<replaceable>msg</replaceable>)</literal> are
   equivalent to calling <literal>plpy.error(<replaceable>msg</replaceable>)</literal> and
   <literal>plpy.fatal(<replaceable>msg</replaceable>)</literal>, respectively but
   the <literal>raise</literal> form does not allow passing keyword arguments.
   The other functions only generate messages of different priority levels.
   Whether messages of a particular priority are reported to the client,
   written to the server log, or both is controlled by the
   <xref linkend="guc-log-min-messages"/> and
   <xref linkend="guc-client-min-messages"/> configuration
   variables. See <xref linkend="runtime-config"/> for more information.
  </para>

  <para>
   The <replaceable>msg</replaceable> argument is given as a positional argument.  For
   backward compatibility, more than one positional argument can be given. In
   that case, the string representation of the tuple of positional arguments
   becomes the message reported to the client.
  </para>

  <para>
   The following keyword-only arguments are accepted:
   <simplelist>
    <member><literal>detail</literal></member>
    <member><literal>hint</literal></member>
    <member><literal>sqlstate</literal></member>
    <member><literal>schema_name</literal></member>
    <member><literal>table_name</literal></member>
    <member><literal>column_name</literal></member>
    <member><literal>datatype_name</literal></member>
    <member><literal>constraint_name</literal></member>
   </simplelist>
   The string representation of the objects passed as keyword-only arguments
   is used to enrich the messages reported to the client. For example:

<programlisting>
CREATE FUNCTION raise_custom_exception() RETURNS void AS $$
plpy.error("custom exception message",
           detail="some info about exception",
           hint="hint for users")
$$ LANGUAGE plpython3u;

=# SELECT raise_custom_exception();
ERROR:  plpy.Error: custom exception message
DETAIL:  some info about exception
HINT:  hint for users
CONTEXT:  Traceback (most recent call last):
  PL/Python function "raise_custom_exception", line 4, in &lt;module&gt;
    hint="hint for users")
PL/Python function "raise_custom_exception"
</programlisting>
  </para>

  <para>

Title: PL/Python Error Handling and Logging
Summary
PL/Python's plpy.error and plpy.fatal functions raise Python exceptions that can abort transactions if uncaught, while other logging functions generate messages with different priority levels, with message reporting controlled by configuration variables and keyword-only arguments available to enrich error messages.