primary control file
     <literal><replaceable>extension</replaceable>.control</literal>,
     an extension can have secondary control files named in the style
     <literal><replaceable>extension</replaceable>--<replaceable>version</replaceable>.control</literal>.
     If supplied, these must be located in the script file directory.
     Secondary control files follow the same format as the primary control
     file.  Any parameters set in a secondary control file override the
     primary control file when installing or updating to that version of
     the extension.  However, the parameters <varname>directory</varname> and
     <varname>default_version</varname> cannot be set in a secondary control file.
    </para>

    <para>
     An extension's <acronym>SQL</acronym> script files can contain any SQL commands,
     except for transaction control commands (<command>BEGIN</command>,
     <command>COMMIT</command>, etc.) and commands that cannot be executed inside a
     transaction block (such as <command>VACUUM</command>).  This is because the
     script files are implicitly executed within a transaction block.
    </para>

    <para>
     An extension's <acronym>SQL</acronym> script files can also contain lines
     beginning with <literal>\echo</literal>, which will be ignored (treated as
     comments) by the extension mechanism.  This provision is commonly used
     to throw an error if the script file is fed to <application>psql</application>
     rather than being loaded via <command>CREATE EXTENSION</command> (see example
     script in <xref linkend="extend-extensions-example"/>).
     Without that, users might accidentally load the
     extension's contents as <quote>loose</quote> objects rather than as an
     extension, a state of affairs that's a bit tedious to recover from.
    </para>

    <para>
     If the extension script contains the
     string <literal>@extowner@</literal>, that string is replaced with the
     (suitably quoted) name of the user calling <command>CREATE
     EXTENSION</command> or <command>ALTER EXTENSION</command>.  Typically
     this feature is used by extensions that are marked trusted to assign
     ownership of selected objects to the calling user rather than the
     bootstrap superuser.  (One should be careful about doing so, however.
     For example, assigning ownership of a C-language function to a
     non-superuser would create a privilege escalation path for that user.)
    </para>

    <para>
     While the script files can contain any characters allowed by the specified
     encoding, control files should contain only plain ASCII, because there
     is no way for <productname>PostgreSQL</productname> to know what encoding a
     control file is in.  In practice this is only an issue if you want to
     use non-ASCII characters in the extension's comment.  Recommended
     practice in that case is to not use the control file <varname>comment</varname>
     parameter, but instead use <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