<type>anycompatiblearray</type>
     positions are automatically cast to the array type for that type.
    </para>

    <para>
     Since there is no way to select a range type knowing only its subtype,
     use of <type>anycompatiblerange</type> and/or
     <type>anycompatiblemultirange</type> requires that all arguments declared
     with that type have the same actual range and/or multirange type, and that
     that type's subtype agree with the selected common type, so that no casting
     of the range values is required.  As with <type>anyrange</type> and
     <type>anymultirange</type>, use of <type>anycompatiblerange</type> and
     <type>anymultirange</type> as a function result type requires that there be
     an <type>anycompatiblerange</type> or <type>anycompatiblemultirange</type>
     argument.
    </para>

    <para>
     Notice that there is no <type>anycompatibleenum</type> type.  Such a
     type would not be very useful, since there normally are not any
     implicit casts to enum types, meaning that there would be no way to
     resolve a common type for dissimilar enum inputs.
    </para>

    <para>
     The <quote>simple</quote> and <quote>common</quote> polymorphic
     families represent two independent sets of type variables.  Consider
     for example
<programlisting>
CREATE FUNCTION myfunc(a anyelement, b anyelement,
                       c anycompatible, d anycompatible)
RETURNS anycompatible AS ...
</programlisting>
     In an actual call of this function, the first two inputs must have
     exactly the same type.  The last two inputs must be promotable to a
     common type, but this type need not have anything to do with the type
     of the first two inputs.  The result will have the common type of the
     last two inputs.
    </para>

    <para>
     A variadic function (one taking a variable number of arguments, as in
     <xref linkend="xfunc-sql-variadic-functions"/>) can be
     polymorphic: this is accomplished by declaring its last parameter as
     <literal>VARIADIC</literal> <type>anyarray</type> or
     <literal>VARIADIC</literal> <type>anycompatiblearray</type>.
     For purposes of argument
     matching and determining the actual result type, such a function behaves
     the same as if you had written the appropriate number of
     <type>anynonarray</type> or <type>anycompatiblenonarray</type>
     parameters.
    </para>
   </sect2>
  </sect1>

  &xfunc;
  &xaggr;
  &xtypes;
  &xoper;
  &xindex;


  <sect1 id="extend-extensions">
   <title>Packaging Related Objects into an Extension</title>

   <indexterm zone="extend-extensions">
    <primary>extension</primary>
   </indexterm>

   <para>
    A useful extension to <productname>PostgreSQL</productname> typically includes
    multiple SQL objects; for example, a new data type will require new
    functions, new operators, and probably new index operator classes.
    It is helpful to collect all these objects into a single package
    to simplify database management.  <productname>PostgreSQL</productname> calls
    such a package an <firstterm>extension</firstterm>.  To define an extension,
    you need at least a <firstterm>script file</firstterm> that contains the
    <acronym>SQL</acronym> commands to create the extension's objects, and a
    <firstterm>control file</firstterm> that specifies a few basic properties
    of the extension itself.  If the extension includes C code, there
    will typically also be a shared library file into which the C code
    has been built.  Once you have these files, a simple
    <link linkend="sql-createextension"><command>CREATE EXTENSION</command></link> command loads the objects into
    your database.
   </para>

   <para>
    The main advantage of using an extension, rather than just running the
    <acronym>SQL</acronym> script to load a bunch of <quote>loose</quote> objects
    into your database, is that <productname>PostgreSQL</productname> will then
    understand that the objects of