interpreter has to be created because a PL/Tcl
        function is called by a new SQL role.
       </para>

       <para>
        The referenced function must be written in the <literal>pltcl</literal>
        language, and must not be marked <literal>SECURITY DEFINER</literal>.
        (These restrictions ensure that it runs in the interpreter it's
        supposed to initialize.)  The current user must have permission to
        call it, too.
       </para>

       <para>
        If the function fails with an error it will abort the function call
        that caused the new interpreter to be created and propagate out to
        the calling query, causing the current transaction or subtransaction
        to be aborted.  Any actions already done within Tcl won't be undone;
        however, that interpreter won't be used again.  If the language is
        used again the initialization will be attempted again within a fresh
        Tcl interpreter.
       </para>

       <para>
        Only superusers can change this setting.  Although this setting
        can be changed within a session, such changes will not affect Tcl
        interpreters that have already been created.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-pltclu-start-proc" xreflabel="pltclu.start_proc">
      <term>
       <varname>pltclu.start_proc</varname> (<type>string</type>)
       <indexterm>
        <primary><varname>pltclu.start_proc</varname> configuration parameter</primary>
       </indexterm>
      </term>
      <listitem>
       <para>
        This parameter is exactly like <varname>pltcl.start_proc</varname>,
        except that it applies to PL/TclU.  The referenced function must
        be written in the <literal>pltclu</literal> language.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </sect1>

   <sect1 id="pltcl-procnames">
    <title>Tcl Procedure Names</title>

    <para>
     In <productname>PostgreSQL</productname>, the same function name can be used for
     different function definitions if the functions are placed in different
     schemas, or if the number of arguments or their types
     differ. Tcl, however, requires all procedure names to be distinct.
     PL/Tcl deals with this by including the argument type names in the
     internal Tcl procedure name, and then appending the function's object
     ID (OID) to the internal Tcl procedure name if necessary to make it
     different from the names of all previously-loaded functions in the
     same Tcl interpreter.  Thus,
     <productname>PostgreSQL</productname> functions with the same name
     and different argument types will be different Tcl procedures, too.  This
     is not normally a concern for a PL/Tcl programmer, but it might be visible
     when debugging.
    </para>

    <para>
     For this reason among others, a PL/Tcl function cannot call another one
     directly (that is, within Tcl).  If you need to do that, you must go
     through SQL, using <function>spi_exec</function> or a related command.
    </para>

   </sect1>
 </chapter>