<sect2 id="extend-extensions-update-scripts">
    <title>Installing Extensions Using Update Scripts</title>

    <para>
     An extension that has been around for awhile will probably exist in
     several versions, for which the author will need to write update scripts.
     For example, if you have released a <literal>foo</literal> extension in
     versions <literal>1.0</literal>, <literal>1.1</literal>, and <literal>1.2</literal>, there
     should be update scripts <filename>foo--1.0--1.1.sql</filename>
     and <filename>foo--1.1--1.2.sql</filename>.
     Before <productname>PostgreSQL</productname> 10, it was necessary to also create
     new script files <filename>foo--1.1.sql</filename> and <filename>foo--1.2.sql</filename>
     that directly build the newer extension versions, or else the newer
     versions could not be installed directly, only by
     installing <literal>1.0</literal> and then updating.  That was tedious and
     duplicative, but now it's unnecessary, because <command>CREATE
     EXTENSION</command> can follow update chains automatically.
     For example, if only the script
     files <filename>foo--1.0.sql</filename>, <filename>foo--1.0--1.1.sql</filename>,
     and <filename>foo--1.1--1.2.sql</filename> are available then a request to
     install version <literal>1.2</literal> is honored by running those three
     scripts in sequence.  The processing is the same as if you'd first
     installed <literal>1.0</literal> and then updated to <literal>1.2</literal>.
     (As with <command>ALTER EXTENSION UPDATE</command>, if multiple pathways are
     available then the shortest is preferred.)  Arranging an extension's
     script files in this style can reduce the amount of maintenance effort
     needed to produce small updates.
    </para>

    <para>
     If you use secondary (version-specific) control files with an extension
     maintained in this style, keep in mind that each version needs a control
     file even if it has no stand-alone installation script, as that control
     file will determine how the implicit update to that version is performed.
     For example, if <filename>foo--1.0.control</filename> specifies <literal>requires
     = 'bar'</literal> but <literal>foo</literal>'s other control files do not, the
     extension's dependency on <literal>bar</literal> will be dropped when updating
     from <literal>1.0</literal> to another version.
    </para>
   </sect2>

   <sect2 id="extend-extensions-security">
    <title>Security Considerations for Extensions</title>

    <para>
     Widely-distributed extensions should assume little about the database
     they occupy.  Therefore, it's appropriate to write functions provided
     by an extension in a secure style that cannot be compromised by
     search-path-based attacks.
    </para>

    <para>
     An extension that has the <varname>superuser</varname> property set to
     true must also consider security hazards for the actions taken within
     its installation and update scripts.  It is not terribly difficult for
     a malicious user to create trojan-horse objects that will compromise
     later execution of a carelessly-written extension script, allowing that
     user to acquire superuser privileges.
    </para>

    <para>
     If an extension is marked <varname>trusted</varname>, then its
     installation schema can be selected by the installing user, who might
     intentionally use an insecure schema in hopes of gaining superuser
     privileges.  Therefore, a trusted extension is extremely exposed from a
     security standpoint, and all its script commands must be carefully
     examined to ensure that no compromise is possible.
    </para>

    <para>
     Advice about writing functions securely is provided in
     <xref linkend="extend-extensions-security-funcs"/> below, and advice
     about writing installation scripts securely is provided in
     <xref linkend="extend-extensions-security-scripts"/>.
    </para>