<command>COMMENT ON EXTENSION</command>
     within a script file to set the comment.
    </para>

   </sect2>

   <sect2 id="extend-extensions-relocation">
    <title>Extension Relocatability</title>

    <para>
     Users often wish to load the objects contained in an extension into a
     different schema than the extension's author had in mind.  There are
     three supported levels of relocatability:
    </para>

    <itemizedlist>
     <listitem>
      <para>
       A fully relocatable extension can be moved into another schema
       at any time, even after it's been loaded into a database.
       This is done with the <command>ALTER EXTENSION SET SCHEMA</command>
       command, which automatically renames all the member objects into
       the new schema.  Normally, this is only possible if the extension
       contains no internal assumptions about what schema any of its
       objects are in.  Also, the extension's objects must all be in one
       schema to begin with (ignoring objects that do not belong to any
       schema, such as procedural languages).  Mark a fully relocatable
       extension by setting <literal>relocatable = true</literal> in its control
       file.
      </para>
     </listitem>

     <listitem>
      <para>
       An extension might be relocatable during installation but not
       afterwards.  This is typically the case if the extension's script
       file needs to reference the target schema explicitly, for example
       in setting <literal>search_path</literal> properties for SQL functions.
       For such an extension, set <literal>relocatable = false</literal> in its
       control file, and use <literal>@extschema@</literal> to refer to the target
       schema in the script file.  All occurrences of this string will be
       replaced by the actual target schema's name (double-quoted if
       necessary) before the script is executed.  The user can set the
       target schema using the
       <literal>SCHEMA</literal> option of <command>CREATE EXTENSION</command>.
      </para>
     </listitem>

     <listitem>
      <para>
       If the extension does not support relocation at all, set
       <literal>relocatable = false</literal> in its control file, and also set
       <literal>schema</literal> to the name of the intended target schema.  This
       will prevent use of the <literal>SCHEMA</literal> option of <command>CREATE
       EXTENSION</command>, unless it specifies the same schema named in the control
       file.  This choice is typically necessary if the extension contains
       internal assumptions about its schema name that can't be replaced by
       uses of <literal>@extschema@</literal>.  The <literal>@extschema@</literal>
       substitution mechanism is available in this case too, although it is
       of limited use since the schema name is determined by the control file.
      </para>
     </listitem>
    </itemizedlist>

    <para>
     In all cases, the script file will be executed with
     <xref linkend="guc-search-path"/> initially set to point to the target
     schema; that is, <command>CREATE EXTENSION</command> does the equivalent of
     this:
<programlisting>
SET LOCAL search_path TO @extschema@, pg_temp;
</programlisting>
     This allows the objects created by the script file to go into the target
     schema.  The script file can change <varname>search_path</varname> if it wishes,
     but that is generally undesirable.  <varname>search_path</varname> is restored
     to its previous setting upon completion of <command>CREATE EXTENSION</command>.
    </para>

    <para>
     The target schema is determined by the <varname>schema</varname> parameter in
     the control file if that is given, otherwise by the <literal>SCHEMA</literal>
     option of <command>CREATE EXTENSION</command> if that is given, otherwise the
     current default object creation schema (the first one in the caller's
     <varname>search_path</varname>).  When the control file