database management.  <productname>PostgreSQL</productname> calls
    such a package an <firstterm>extension</firstterm>.  To define an extension,
    you need at least a <firstterm>script file</firstterm> that contains the
    <acronym>SQL</acronym> commands to create the extension's objects, and a
    <firstterm>control file</firstterm> that specifies a few basic properties
    of the extension itself.  If the extension includes C code, there
    will typically also be a shared library file into which the C code
    has been built.  Once you have these files, a simple
    <link linkend="sql-createextension"><command>CREATE EXTENSION</command></link> command loads the objects into
    your database.
   </para>

   <para>
    The main advantage of using an extension, rather than just running the
    <acronym>SQL</acronym> script to load a bunch of <quote>loose</quote> objects
    into your database, is that <productname>PostgreSQL</productname> will then
    understand that the objects of the extension go together.  You can
    drop all the objects with a single <link linkend="sql-dropextension"><command>DROP EXTENSION</command></link>
    command (no need to maintain a separate <quote>uninstall</quote> script).
    Even more useful, <application>pg_dump</application> knows that it should not
    dump the individual member objects of the extension &mdash; it will
    just include a <command>CREATE EXTENSION</command> command in dumps, instead.
    This vastly simplifies migration to a new version of the extension
    that might contain more or different objects than the old version.
    Note however that you must have the extension's control, script, and
    other files available when loading such a dump into a new database.
   </para>

   <para>
    <productname>PostgreSQL</productname> will not let you drop an individual object
    contained in an extension, except by dropping the whole extension.
    Also, while you can change the definition of an extension member object
    (for example, via <command>CREATE OR REPLACE FUNCTION</command> for a
    function), bear in mind that the modified definition will not be dumped
    by <application>pg_dump</application>.  Such a change is usually only sensible if
    you concurrently make the same change in the extension's script file.
    (But there are special provisions for tables containing configuration
    data; see <xref linkend="extend-extensions-config-tables"/>.)
    In production situations, it's generally better to create an extension
    update script to perform changes to extension member objects.
   </para>

   <para>
    The extension script may set privileges on objects that are part of the
    extension, using <command>GRANT</command> and <command>REVOKE</command>
    statements.  The final set of privileges for each object (if any are set)
    will be stored in the
    <link linkend="catalog-pg-init-privs"><structname>pg_init_privs</structname></link>
    system catalog.  When <application>pg_dump</application> is used, the
    <command>CREATE EXTENSION</command> command will be included in the dump, followed
    by the set of <command>GRANT</command> and <command>REVOKE</command>
    statements necessary to set the privileges on the objects to what they were
    at the time the dump was taken.
   </para>

   <para>
    <productname>PostgreSQL</productname> does not currently support extension scripts
    issuing <command>CREATE POLICY</command> or <command>SECURITY LABEL</command>
    statements.  These are expected to be set after the extension has been
    created.  All RLS policies and security labels on extension objects will be
    included in dumps created by <application>pg_dump</application>.
   </para>

   <para>
    The extension mechanism also has provisions for packaging modification
    scripts that adjust the definitions of the SQL objects contained in an
    extension.  For example, if version 1.1 of an extension adds one function
    and changes the