Home Explore Blog CI



postgresql

42th chunk of `doc/src/sgml/catalogs.sgml`
cb602def1ea2ffa176def0dce6ba4f530f4e20f0858da14f0000000100000fa2
   <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>refclassid</structfield> <type>oid</type>
       (references <link linkend="catalog-pg-class"><structname>pg_class</structname></link>.<structfield>oid</structfield>)
      </para>
      <para>
       The OID of the system catalog the referenced object is in
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>refobjid</structfield> <type>oid</type>
       (references any OID column)
      </para>
      <para>
       The OID of the specific referenced object
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>refobjsubid</structfield> <type>int4</type>
      </para>
      <para>
       For a table column, this is the column number (the
       <structfield>refobjid</structfield> and <structfield>refclassid</structfield> refer
       to the table itself).  For all other object types, this column
       is zero.
      </para></entry>
     </row>

     <row>
      <entry role="catalog_table_entry"><para role="column_definition">
       <structfield>deptype</structfield> <type>char</type>
      </para>
      <para>
       A code defining the specific semantics of this dependency relationship; see text
      </para></entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   In all cases, a <structname>pg_depend</structname> entry indicates that the
   referenced object cannot be dropped without also dropping the dependent
   object.  However, there are several subflavors identified by
   <structfield>deptype</structfield>:

   <variablelist>
    <varlistentry>
     <term><symbol>DEPENDENCY_NORMAL</symbol> (<literal>n</literal>)</term>
     <listitem>
      <para>
       A normal relationship between separately-created objects.  The
       dependent object can be dropped without affecting the
       referenced object.  The referenced object can only be dropped
       by specifying <literal>CASCADE</literal>, in which case the dependent
       object is dropped, too.  Example: a table column has a normal
       dependency on its data type.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><symbol>DEPENDENCY_AUTO</symbol> (<literal>a</literal>)</term>
     <listitem>
      <para>
       The dependent object can be dropped separately from the
       referenced object, and should be automatically dropped
       (regardless of <literal>RESTRICT</literal> or <literal>CASCADE</literal>
       mode) if the referenced object is dropped.  Example: a named
       constraint on a table is made auto-dependent on the table, so
       that it will go away if the table is dropped.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><symbol>DEPENDENCY_INTERNAL</symbol> (<literal>i</literal>)</term>
     <listitem>
      <para>
       The dependent object was created as part of creation of the
       referenced object, and is really just a part of its internal
       implementation.  A direct <command>DROP</command> of the dependent
       object will be disallowed outright (we'll tell the user to issue
       a <command>DROP</command> against the referenced object, instead).
       A <command>DROP</command> of the referenced object will result in
       automatically dropping the dependent object
       whether <literal>CASCADE</literal> is specified or not.  If the
       dependent object has to be dropped due to a dependency on some other
       object being removed, its drop is converted to a drop of the referenced
       object, so that <literal>NORMAL</literal> and <literal>AUTO</literal>
       dependencies of the dependent object behave much like they were
       dependencies of the referenced object.
       Example: a view's <literal>ON SELECT</literal> rule is made
       internally dependent on the view,

Title: pg_depend Catalog Columns and Dependency Types
Summary
This section details the remaining columns of the pg_depend catalog: refobjsubid and deptype. It explains the 'deptype' column, which defines the semantics of the dependency relationship. Three dependency types are described: DEPENDENCY_NORMAL ('n'), a normal relationship where the dependent object can be dropped without affecting the referenced object; DEPENDENCY_AUTO ('a'), where the dependent object is automatically dropped if the referenced object is dropped; and DEPENDENCY_INTERNAL ('i'), where the dependent object is part of the referenced object's internal implementation and cannot be dropped directly.