<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>
   Another set of utility functions are
   <literal>plpy.quote_literal(<replaceable>string</replaceable>)</literal>,
   <literal>plpy.quote_nullable(<replaceable>string</replaceable>)</literal>, and
   <literal>plpy.quote_ident(<replaceable>string</replaceable>)</literal>.  They
   are equivalent to the built-in quoting functions described in <xref
   linkend="functions-string"/>.  They are useful when constructing
   ad-hoc queries.  A PL/Python equivalent of dynamic SQL from <xref
   linkend="plpgsql-quote-literal-example"/> would be:
<programlisting>
plpy.execute("UPDATE tbl SET %s = %s WHERE key = %s" % (
    plpy.quote_ident(colname),
    plpy.quote_nullable(newvalue),
    plpy.quote_literal(keyvalue)))
</programlisting>
  </para>
 </sect1>

 <sect1 id="plpython-python23">
  <title>Python 2 vs. Python 3</title>

  <para>
   PL/Python supports only Python 3. Past versions of
   <productname>PostgreSQL</productname> supported Python 2, using the
   <literal>plpythonu</literal> and <literal>plpython2u</literal> language
   names.
  </para>
 </sect1>

 <sect1 id="plpython-envar">
  <title>Environment Variables</title>

  <para>
   Some of the environment variables that are accepted by the Python
   interpreter can also be used to affect PL/Python behavior.  They
   would need to be set in the environment of the main PostgreSQL
   server process, for example in a start script.  The available
   environment variables depend on the version of Python; see the
   Python documentation for details.  At the time of this writing, the
   following environment variables have an affect on PL/Python,
   assuming an adequate Python version:
   <itemizedlist>
    <listitem>
     <para><envar>PYTHONHOME</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONPATH</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONY2K</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONOPTIMIZE</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONDEBUG</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONVERBOSE</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONCASEOK</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONDONTWRITEBYTECODE</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONIOENCODING</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONUSERBASE</envar></para>
    </listitem>

    <listitem>
     <para><envar>PYTHONHASHSEED</envar></para>
    </listitem>
   </itemizedlist>

   (It appears to be a Python implementation detail beyond the control
   of PL/Python that some of the environment variables listed on
   the <command>python</command> man page are only effective in a
   command-line interpreter and not an embedded Python interpreter.)
  </para>
 </sect1>
</chapter>