Home • Explore • Blog • CI
☰



postgresql
44th chunk of `doc/src/sgml/catalogs.sgml`
4ff8bb85c8b3f3a38096ceb1fdd88db5601117e606362de50000000100000fa2
 partition dependencies need only be added or removed.
       Example: a child partitioned index is made partition-dependent
       on both the partition table it is on and the parent partitioned
       index, so that it goes away if either of those is dropped, but
       not otherwise.  The dependency on the parent index is primary,
       so that if the user tries to drop the child partitioned index,
       the error message will suggest dropping the parent index instead
       (not the table).
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><symbol>DEPENDENCY_EXTENSION</symbol> (<literal>e</literal>)</term>
     <listitem>
      <para>
       The dependent object is a member of the <firstterm>extension</firstterm> that is
       the referenced object (see
       <link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>).
       The dependent object can be dropped only via
       <link linkend="sql-dropextension"><command>DROP EXTENSION</command></link> on the referenced object.
       Functionally this dependency type acts the same as
       an <literal>INTERNAL</literal> dependency, but it's kept separate for
       clarity and to simplify <application>pg_dump</application>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><symbol>DEPENDENCY_AUTO_EXTENSION</symbol> (<literal>x</literal>)</term>
     <listitem>
      <para>
       The dependent object is not a member of the extension that is the
       referenced object (and so it should not be ignored
       by <application>pg_dump</application>), but it cannot function
       without the extension and should be auto-dropped if the extension is.
       The dependent object may be dropped on its own as well.
       Functionally this dependency type acts the same as
       an <literal>AUTO</literal> dependency, but it's kept separate for
       clarity and to simplify <application>pg_dump</application>.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

   Other dependency flavors might be needed in future.
  </para>

  <para>
   Note that it's quite possible for two objects to be linked by more than
   one <structname>pg_depend</structname> entry.  For example, a child
   partitioned index would have both a partition-type dependency on its
   associated partition table, and an auto dependency on each column of
   that table that it indexes.  This sort of situation expresses the union
   of multiple dependency semantics.  A dependent object can be dropped
   without <literal>CASCADE</literal> if any of its dependencies satisfies
   its condition for automatic dropping.  Conversely, all the
   dependencies' restrictions about which objects must be dropped together
   must be satisfied.
  </para>

  <para>
   Most objects created during <application>initdb</application> are
   considered <quote>pinned</quote>, which means that the system itself
   depends on them.  Therefore, they are never allowed to be dropped.
   Also, knowing that pinned objects will not be dropped, the dependency
   mechanism doesn't bother to make <structname>pg_depend</structname>
   entries showing dependencies on them.  Thus, for example, a table
   column of type <type>numeric</type> notionally has
   a <literal>NORMAL</literal> dependency on the <type>numeric</type>
   data type, but no such entry actually appears
   in <structname>pg_depend</structname>.
  </para>

 </sect1>


 <sect1 id="catalog-pg-description">
  <title><structname>pg_description</structname></title>

  <indexterm zone="catalog-pg-description">
   <primary>pg_description</primary>
  </indexterm>

  <para>
   The catalog <structname>pg_description</structname> stores optional descriptions
   (comments) for each database object.  Descriptions can be manipulated
   with the <link linkend="sql-comment"><command>COMMENT</command></link> command and viewed with
   <application>psql</application>'s <literal>\d</literal> commands.
Title: pg_depend Dependency Types: Extension, Auto Extension, and Multiple Dependencies
Summary
This section describes DEPENDENCY_EXTENSION ('e'), where the dependent object is part of an extension and can only be dropped via DROP EXTENSION, and DEPENDENCY_AUTO_EXTENSION ('x'), where the dependent object requires the extension but isn't a member, and is auto-dropped if the extension is. It also explains that objects can have multiple dependencies, expressing a union of dependency semantics, and discusses pinned objects created during initdb, which are never dropped and thus don't have dependency entries.