Sophie

Sophie

distrib > Mageia > 7 > armv7hl > media > core-updates > by-pkgid > 5fea23694c765462b86d6ddf74461eab > files > 569

postgresql9.6-docs-9.6.22-1.mga7.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Utility Functions</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.6.22 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="PL/Python - Python Procedural Language"
HREF="plpython.html"><LINK
REL="PREVIOUS"
TITLE="Explicit Subtransactions"
HREF="plpython-subtransaction.html"><LINK
REL="NEXT"
TITLE="Environment Variables"
HREF="plpython-envar.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2021-05-18T09:16:10"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="4"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.6.22 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Explicit Subtransactions"
HREF="plpython-subtransaction.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="plpython.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 44. PL/Python - Python Procedural Language</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Environment Variables"
HREF="plpython-envar.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PLPYTHON-UTIL"
>44.9. Utility Functions</A
></H1
><P
>   The <TT
CLASS="LITERAL"
>plpy</TT
> module also provides the functions
   <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.debug(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.log(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.info(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.notice(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.warning(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.error(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>plpy.fatal(<TT
CLASS="REPLACEABLE"
><I
>msg, **kwargs</I
></TT
>)</TT
></TD
></TR
></TBODY
></TABLE
><P
></P
>
   
   <CODE
CLASS="FUNCTION"
>plpy.error</CODE
> and <CODE
CLASS="FUNCTION"
>plpy.fatal</CODE
>
   actually raise a Python exception which, if uncaught, propagates out to
   the calling query, causing the current transaction or subtransaction to
   be aborted.  <TT
CLASS="LITERAL"
>raise plpy.Error(<TT
CLASS="REPLACEABLE"
><I
>msg</I
></TT
>)</TT
> and
   <TT
CLASS="LITERAL"
>raise plpy.Fatal(<TT
CLASS="REPLACEABLE"
><I
>msg</I
></TT
>)</TT
> are
   equivalent to calling <TT
CLASS="LITERAL"
>plpy.error(<TT
CLASS="REPLACEABLE"
><I
>msg</I
></TT
>)</TT
> and
   <TT
CLASS="LITERAL"
>plpy.fatal(<TT
CLASS="REPLACEABLE"
><I
>msg</I
></TT
>)</TT
>, respectively but
   the <TT
CLASS="LITERAL"
>raise</TT
> 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
   <A
HREF="runtime-config-logging.html#GUC-LOG-MIN-MESSAGES"
>log_min_messages</A
> and
   <A
HREF="runtime-config-client.html#GUC-CLIENT-MIN-MESSAGES"
>client_min_messages</A
> configuration
   variables. See <A
HREF="runtime-config.html"
>Chapter 19</A
> for more information.
  </P
><P
>   The <TT
CLASS="REPLACEABLE"
><I
>msg</I
></TT
> 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.
  </P
><P
>   The following keyword-only arguments are accepted:
   <P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
><TT
CLASS="LITERAL"
>detail</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>hint</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>sqlstate</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>schema_name</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>table_name</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>column_name</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>datatype_name</TT
></TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>constraint_name</TT
></TD
></TR
></TBODY
></TABLE
><P
></P
>
   The string representation of the objects passed as keyword-only arguments
   is used to enrich the messages reported to the client. For example:

</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION raise_custom_exception() RETURNS void AS $$
plpy.error("custom exception message",
           detail="some info about exception",
           hint="hint for users")
$$ LANGUAGE plpythonu;

=# 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"</PRE
><P>
  </P
><P
>   Another set of utility functions are
   <TT
CLASS="LITERAL"
>plpy.quote_literal(<TT
CLASS="REPLACEABLE"
><I
>string</I
></TT
>)</TT
>,
   <TT
CLASS="LITERAL"
>plpy.quote_nullable(<TT
CLASS="REPLACEABLE"
><I
>string</I
></TT
>)</TT
>, and
   <TT
CLASS="LITERAL"
>plpy.quote_ident(<TT
CLASS="REPLACEABLE"
><I
>string</I
></TT
>)</TT
>.  They
   are equivalent to the built-in quoting functions described in <A
HREF="functions-string.html"
>Section 9.4</A
>.  They are useful when constructing
   ad-hoc queries.  A PL/Python equivalent of dynamic SQL from <A
HREF="plpgsql-statements.html#PLPGSQL-QUOTE-LITERAL-EXAMPLE"
>Example 41-1</A
> would be:
</P><PRE
CLASS="PROGRAMLISTING"
>plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % (
    plpy.quote_ident(colname),
    plpy.quote_nullable(newvalue),
    plpy.quote_literal(keyvalue)))</PRE
><P>
  </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="plpython-subtransaction.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="plpython-envar.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Explicit Subtransactions</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="plpython.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Environment Variables</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>