EXTENSION</command> provides for installation
     scripts: in particular, <varname>search_path</varname> is set up in the same
     way, and any new objects created by the script are automatically added
     to the extension.  Also, if the script chooses to drop extension member
     objects, they are automatically dissociated from the extension.
    </para>

    <para>
     If an extension has secondary control files, the control parameters
     that are used for an update script are those associated with the script's
     target (new) version.
    </para>

    <para>
     <command>ALTER EXTENSION</command> is able to execute sequences of update
     script files to achieve a requested update.  For example, if only
     <literal>foo--1.0--1.1.sql</literal> and <literal>foo--1.1--2.0.sql</literal> are
     available, <command>ALTER EXTENSION</command> will apply them in sequence if an
     update to version <literal>2.0</literal> is requested when <literal>1.0</literal> is
     currently installed.
    </para>

    <para>
     <productname>PostgreSQL</productname> doesn't assume anything about the properties
     of version names: for example, it does not know whether <literal>1.1</literal>
     follows <literal>1.0</literal>.  It just matches up the available version names
     and follows the path that requires applying the fewest update scripts.
     (A version name can actually be any string that doesn't contain
     <literal>--</literal> or leading or trailing <literal>-</literal>.)
    </para>

    <para>
     Sometimes it is useful to provide <quote>downgrade</quote> scripts, for
     example <literal>foo--1.1--1.0.sql</literal> to allow reverting the changes
     associated with version <literal>1.1</literal>.  If you do that, be careful
     of the possibility that a downgrade script might unexpectedly
     get applied because it yields a shorter path.  The risky case is where
     there is a <quote>fast path</quote> update script that jumps ahead several
     versions as well as a downgrade script to the fast path's start point.
     It might take fewer steps to apply the downgrade and then the fast
     path than to move ahead one version at a time.  If the downgrade script
     drops any irreplaceable objects, this will yield undesirable results.
    </para>

    <para>
     To check for unexpected update paths, use this command:
<programlisting>
SELECT * FROM pg_extension_update_paths('<replaceable>extension_name</replaceable>');
</programlisting>
     This shows each pair of distinct known version names for the specified
     extension, together with the update path sequence that would be taken to
     get from the source version to the target version, or <literal>NULL</literal> if
     there is no available update path.  The path is shown in textual form
     with <literal>--</literal> separators.  You can use
     <literal>regexp_split_to_array(path,'--')</literal> if you prefer an array
     format.
    </para>
   </sect2>

   <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