that the procedure is implemented in.
       It can be <literal>sql</literal>, <literal>c</literal>,
       <literal>internal</literal>, or the name of a user-defined
       procedural language, e.g., <literal>plpgsql</literal>.  The default is
       <literal>sql</literal> if <replaceable
       class="parameter">sql_body</replaceable> is specified.  Enclosing the
       name in single quotes is deprecated and requires matching case.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>TRANSFORM { FOR TYPE <replaceable class="parameter">type_name</replaceable> } [, ... ] }</literal></term>

     <listitem>
      <para>
       Lists which transforms a call to the procedure should apply.  Transforms
       convert between SQL types and language-specific data types;
       see <xref linkend="sql-createtransform"/>.  Procedural language
       implementations usually have hardcoded knowledge of the built-in types,
       so those don't need to be listed here.  If a procedural language
       implementation does not know how to handle a type and no transform is
       supplied, it will fall back to a default behavior for converting data
       types, but this depends on the implementation.
      </para>
     </listitem>
    </varlistentry>

   <varlistentry>
    <term><literal><optional>EXTERNAL</optional> SECURITY INVOKER</literal></term>
    <term><literal><optional>EXTERNAL</optional> SECURITY DEFINER</literal></term>

    <listitem>
     <para><literal>SECURITY INVOKER</literal> indicates that the procedure
      is to be executed with the privileges of the user that calls it.
      That is the default.  <literal>SECURITY DEFINER</literal>
      specifies that the procedure is to be executed with the
      privileges of the user that owns it.
     </para>

     <para>
      The key word <literal>EXTERNAL</literal> is allowed for SQL
      conformance, but it is optional since, unlike in SQL, this feature
      applies to all procedures not only external ones.
     </para>

     <para>
      A <literal>SECURITY DEFINER</literal> procedure cannot execute
      transaction control statements (for example, <command>COMMIT</command>
      and <command>ROLLBACK</command>, depending on the language).
     </para>
    </listitem>
   </varlistentry>

    <varlistentry>
     <term><replaceable>configuration_parameter</replaceable></term>
     <term><replaceable>value</replaceable></term>
     <listitem>
      <para>
       The <literal>SET</literal> clause causes the specified configuration
       parameter to be set to the specified value when the procedure is
       entered, and then restored to its prior value when the procedure exits.
       <literal>SET FROM CURRENT</literal> saves the value of the parameter that
       is current when <command>CREATE PROCEDURE</command> is executed as the value
       to be applied when the procedure is entered.
      </para>

      <para>
       If a <literal>SET</literal> clause is attached to a procedure, then
       the effects of a <command>SET LOCAL</command> command executed inside the
       procedure for the same variable are restricted to the procedure: the
       configuration parameter's prior value is still restored at procedure exit.
       However, an ordinary
       <command>SET</command> command (without <literal>LOCAL</literal>) overrides the
       <literal>SET</literal> clause, much as it would do for a previous <command>SET
       LOCAL</command> command: the effects of such a command will persist after
       procedure exit, unless the current transaction is rolled back.
      </para>

      <para>
       If a <literal>SET</literal> clause is attached to a procedure, then
       that procedure cannot execute transaction control statements (for
       example, <command>COMMIT</command> and <command>ROLLBACK</command>,
       depending on the language).
      </para>

      <para>
       See <xref linkend="sql-set"/> and
       <xref linkend="runtime-config"/>