inserted into SQL commands given
        to <function>spi_exec</function> or
        <function>spi_prepare</function>.
        For example, think about an SQL command string like:

<programlisting>
"SELECT '$val' AS ret"
</programlisting>

        where the Tcl variable <literal>val</literal> actually contains
        <literal>doesn't</literal>. This would result
        in the final command string:

<programlisting>
SELECT 'doesn't' AS ret
</programlisting>

        which would cause a parse error during
        <function>spi_exec</function> or
        <function>spi_prepare</function>.
        To work properly, the submitted command should contain:

<programlisting>
SELECT 'doesn''t' AS ret
</programlisting>

        which can be formed in PL/Tcl using:

<programlisting>
"SELECT '[ quote $val ]' AS ret"
</programlisting>

        One advantage of <function>spi_execp</function> is that you don't
        have to quote parameter values like this, since the parameters are never
        parsed as part of an SQL command string.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>
       <function>elog</function> <replaceable>level</replaceable> <replaceable>msg</replaceable>
       <indexterm>
        <primary>elog</primary>
        <secondary>in PL/Tcl</secondary>
       </indexterm>
      </term>
      <listitem>
       <para>
        Emits a log or error message. Possible levels are
        <literal>DEBUG</literal>, <literal>LOG</literal>, <literal>INFO</literal>,
        <literal>NOTICE</literal>, <literal>WARNING</literal>, <literal>ERROR</literal>, and
        <literal>FATAL</literal>. <literal>ERROR</literal>
        raises an error condition; if this is not trapped by the surrounding
        Tcl code, the error propagates out to the calling query, causing
        the current transaction or subtransaction to be aborted.  This
        is effectively the same as the Tcl <literal>error</literal> command.
        <literal>FATAL</literal> aborts the transaction and causes the current
        session to shut down.  (There is probably no good reason to use
        this error level in PL/Tcl functions, but it's provided for
        completeness.)  The other levels 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"/>
        and <xref linkend="pltcl-error-handling"/>
        for more information.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
    </para>

   </sect1>

   <sect1 id="pltcl-trigger">
    <title>Trigger Functions in PL/Tcl</title>

    <indexterm>
     <primary>trigger</primary>
     <secondary>in PL/Tcl</secondary>
    </indexterm>

    <para>
     Trigger functions can be written in PL/Tcl.
     <productname>PostgreSQL</productname> requires that a function that is to be called
     as a trigger must be declared as a function with no arguments
     and a return type of <literal>trigger</literal>.
    </para>
    <para>
     The information from the trigger manager is passed to the function body
     in the following variables:

     <variablelist>

      <varlistentry>
       <term><varname>$TG_name</varname></term>
       <listitem>
        <para>
         The name of the trigger from the <command>CREATE TRIGGER</command> statement.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><varname>$TG_relid</varname></term>
       <listitem>
        <para>
         The object ID of the table that caused the trigger function
         to be invoked.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry>
       <term><varname>$TG_table_name</varname></term>
       <listitem>
        <para>