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 <varname>schema</varname>
     parameter is used, the target schema will be created if it doesn't
     already exist, but in the other two cases it must already exist.
    </para>

    <para>
     If any prerequisite extensions are listed in <varname>requires</varname>
     in the control file, their target schemas are added to the initial
     setting of <varname>search_path</varname>, following the new
     extension's target schema.  This allows their objects to be visible to
     the new extension's script file.
    </para>

    <para>
     For security, <literal>pg_temp</literal> is automatically appended to
     the end of <varname>search_path</varname> in all cases.
    </para>

    <para>
     Although a non-relocatable extension can contain objects spread across
     multiple schemas, it is usually desirable to place all the objects meant
     for external use into a single schema, which is considered the extension's
     target schema.  Such an arrangement works conveniently with the default
     setting of <varname>search_path</varname> during creation of dependent
     extensions.
    </para>

    <para>
     If an extension references objects belonging to another extension,
     it is recommended to schema-qualify those references.  To do that,
     write <literal>@extschema:<replaceable>name</replaceable>@</literal>
     in the extension's script file, where <replaceable>name</replaceable>
     is the name of the other extension (which must be listed in this
     extension's <literal>requires</literal> list).  This string will be
     replaced by the name (double-quoted if necessary) of that extension's
     target schema.
     Although this notation avoids the need to make hard-wired assumptions
     about schema names in the extension's script file, its use may embed
     the other extension's schema name into the installed objects of this
     extension.  (Typically, that happens
     when <literal>@extschema:<replaceable>name</replaceable>@</literal> is
     used inside a string literal, such as a function body or
     a <varname>search_path</varname> setting.  In other cases, the object
     reference is reduced to an OID during parsing and does not require
     subsequent lookups.)  If the other extension's schema name is so
     embedded, you should prevent the other extension from being relocated
     after yours is installed, by adding the name of the other extension to
     this one's <literal>no_relocate</literal> list.
    </para>
   </sect2>

   <sect2 id="extend-extensions-config-tables">
    <title>Extension Configuration Tables</title>

    <para>
     Some extensions include configuration tables, which contain data that
     might be added or changed by the user after installation of the
     extension.  Ordinarily, if a table is part of an extension, neither
     the table's definition nor its content will be dumped by
     <application>pg_dump</application>.  But that behavior is undesirable for a
     configuration