<literal>false</literal>, just the privileges
        required to execute the commands in the installation or update script
        are required.
        This should normally be set to <literal>true</literal> if any of the
        script commands require superuser privileges.  (Such commands would
        fail anyway, but it's more user-friendly to give the error up front.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="extend-extensions-files-trusted">
      <term><varname>trusted</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        This parameter, if set to <literal>true</literal> (which is not the
        default), allows some non-superusers to install an extension that
        has <varname>superuser</varname> set to <literal>true</literal>.
        Specifically, installation will be permitted for anyone who has
        <literal>CREATE</literal> privilege on the current database.
        When the user executing <command>CREATE EXTENSION</command> is not
        a superuser but is allowed to install by virtue of this parameter,
        then the installation or update script is run as the bootstrap
        superuser, not as the calling user.
        This parameter is irrelevant if <varname>superuser</varname> is
        <literal>false</literal>.
        Generally, this should not be set true for extensions that could
        allow access to otherwise-superuser-only abilities, such as
        file system access.
        Also, marking an extension trusted requires significant extra effort
        to write the extension's installation and update script(s) securely;
        see <xref linkend="extend-extensions-security"/>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="extend-extensions-files-relocatable">
      <term><varname>relocatable</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        An extension is <firstterm>relocatable</firstterm> if it is possible to move
        its contained objects into a different schema after initial creation
        of the extension.  The default is <literal>false</literal>, i.e., the
        extension is not relocatable.
        See <xref linkend="extend-extensions-relocation"/> for more information.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="extend-extensions-files-schema">
      <term><varname>schema</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        This parameter can only be set for non-relocatable extensions.
        It forces the extension to be loaded into exactly the named schema
        and not any other.
        The <varname>schema</varname> parameter is consulted only when
        initially creating an extension, not during extension updates.
        See <xref linkend="extend-extensions-relocation"/> for more information.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    <para>
     In addition to the 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