<varlistentry>
     <term><literal><replaceable class="parameter">obj_file</replaceable>, <replaceable class="parameter">link_symbol</replaceable></literal></term>

     <listitem>
      <para>
       This form of the <literal>AS</literal> clause is used for
       dynamically loadable C language functions when the function name
       in the C language source code is not the same as the name of
       the SQL function. The string <replaceable
       class="parameter">obj_file</replaceable> is the name of the shared
       library file containing the compiled C function, and is interpreted
       as for the <link linkend="sql-load"><command>LOAD</command></link> command.  The string
       <replaceable class="parameter">link_symbol</replaceable> is the
       function's link symbol, that is, the name of the function in the C
       language source code.  If the link symbol is omitted, it is assumed to
       be the same as the name of the SQL function being defined.  The C names
       of all functions must be different, so you must give overloaded C
       functions different C names (for example, use the argument types as
       part of the C names).
      </para>

      <para>
       When repeated <command>CREATE FUNCTION</command> calls refer to
       the same object file, the file is only loaded once per session.
       To unload and
       reload the file (perhaps during development), start a new session.
      </para>

     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable class="parameter">sql_body</replaceable></term>

     <listitem>
      <para>
       The body of a <literal>LANGUAGE SQL</literal> function.  This can
       either be a single statement
<programlisting>
RETURN <replaceable>expression</replaceable>
</programlisting>
       or a block
<programlisting>
BEGIN ATOMIC
  <replaceable>statement</replaceable>;
  <replaceable>statement</replaceable>;
  ...
  <replaceable>statement</replaceable>;
END
</programlisting>
      </para>

      <para>
       This is similar to writing the text of the function body as a string
       constant (see <replaceable>definition</replaceable> above), but there
       are some differences: This form only works for <literal>LANGUAGE
       SQL</literal>, the string constant form works for all languages.  This
       form is parsed at function definition time, the string constant form is
       parsed at execution time; therefore this form cannot support
       polymorphic argument types and other constructs that are not resolvable
       at function definition time.  This form tracks dependencies between the
       function and objects used in the function body, so <literal>DROP
       ... CASCADE</literal> will work correctly, whereas the form using
       string literals may leave dangling functions.  Finally, this form is
       more compatible with the SQL standard and other SQL implementations.
      </para>
     </listitem>
    </varlistentry>

   </variablelist>
 </refsect1>

 <refsect1 id="sql-createfunction-overloading">
  <title>Overloading</title>

   <para>
    <productname>PostgreSQL</productname> allows function
    <firstterm>overloading</firstterm>; that is, the same name can be
    used for several different functions so long as they have distinct
    input argument types.  Whether or not you use it, this capability entails
    security precautions when calling functions in databases where some users
    mistrust other users; see <xref linkend="typeconv-func"/>.
   </para>

   <para>
    Two functions are considered the same if they have the same names and
    <emphasis>input</emphasis> argument types, ignoring any <literal>OUT</literal>
    parameters.  Thus for example these declarations conflict:
<programlisting>
CREATE FUNCTION foo(int) ...
CREATE FUNCTION foo(int, out text) ...
</programlisting>
   </para>

   <para>
    Functions that have different argument type lists will not be considered
    to conflict at creation time, but