begriffs open source - ai-pg/blob - full-docs/txt/catalog-pg-depend.txt

   1
   2 52.18. pg_depend #
   3
   4    The catalog pg_depend records the dependency relationships between
   5    database objects. This information allows DROP commands to find which
   6    other objects must be dropped by DROP CASCADE or prevent dropping in
   7    the DROP RESTRICT case.
   8
   9    See also pg_shdepend, which performs a similar function for
  10    dependencies involving objects that are shared across a database
  11    cluster.
  12
  13    Table 52.18. pg_depend Columns
  14
  15    Column Type
  16
  17    Description
  18
  19    classid oid (references pg_class.oid)
  20
  21    The OID of the system catalog the dependent object is in
  22
  23    objid oid (references any OID column)
  24
  25    The OID of the specific dependent object
  26
  27    objsubid int4
  28
  29    For a table column, this is the column number (the objid and classid
  30    refer to the table itself). For all other object types, this column is
  31    zero.
  32
  33    refclassid oid (references pg_class.oid)
  34
  35    The OID of the system catalog the referenced object is in
  36
  37    refobjid oid (references any OID column)
  38
  39    The OID of the specific referenced object
  40
  41    refobjsubid int4
  42
  43    For a table column, this is the column number (the refobjid and
  44    refclassid refer to the table itself). For all other object types, this
  45    column is zero.
  46
  47    deptype char
  48
  49    A code defining the specific semantics of this dependency relationship;
  50    see text
  51
  52    In all cases, a pg_depend entry indicates that the referenced object
  53    cannot be dropped without also dropping the dependent object. However,
  54    there are several subflavors identified by deptype:
  55
  56    DEPENDENCY_NORMAL (n)
  57           A normal relationship between separately-created objects. The
  58           dependent object can be dropped without affecting the referenced
  59           object. The referenced object can only be dropped by specifying
  60           CASCADE, in which case the dependent object is dropped, too.
  61           Example: a table column has a normal dependency on its data
  62           type.
  63
  64    DEPENDENCY_AUTO (a)
  65           The dependent object can be dropped separately from the
  66           referenced object, and should be automatically dropped
  67           (regardless of RESTRICT or CASCADE mode) if the referenced
  68           object is dropped. Example: a named constraint on a table is
  69           made auto-dependent on the table, so that it will go away if the
  70           table is dropped.
  71
  72    DEPENDENCY_INTERNAL (i)
  73           The dependent object was created as part of creation of the
  74           referenced object, and is really just a part of its internal
  75           implementation. A direct DROP of the dependent object will be
  76           disallowed outright (we'll tell the user to issue a DROP against
  77           the referenced object, instead). A DROP of the referenced object
  78           will result in automatically dropping the dependent object
  79           whether CASCADE is specified or not. If the dependent object has
  80           to be dropped due to a dependency on some other object being
  81           removed, its drop is converted to a drop of the referenced
  82           object, so that NORMAL and AUTO dependencies of the dependent
  83           object behave much like they were dependencies of the referenced
  84           object. Example: a view's ON SELECT rule is made internally
  85           dependent on the view, preventing it from being dropped while
  86           the view remains. Dependencies of the rule (such as tables it
  87           refers to) act as if they were dependencies of the view.
  88
  89    DEPENDENCY_PARTITION_PRI (P)
  90           DEPENDENCY_PARTITION_SEC (S)
  91           The dependent object was created as part of creation of the
  92           referenced object, and is really just a part of its internal
  93           implementation; however, unlike INTERNAL, there is more than one
  94           such referenced object. The dependent object must not be dropped
  95           unless at least one of these referenced objects is dropped; if
  96           any one is, the dependent object should be dropped whether or
  97           not CASCADE is specified. Also unlike INTERNAL, a drop of some
  98           other object that the dependent object depends on does not
  99           result in automatic deletion of any partition-referenced object.
 100           Hence, if the drop does not cascade to at least one of these
 101           objects via some other path, it will be refused. (In most cases,
 102           the dependent object shares all its non-partition dependencies
 103           with at least one partition-referenced object, so that this
 104           restriction does not result in blocking any cascaded delete.)
 105           Primary and secondary partition dependencies behave identically
 106           except that the primary dependency is preferred for use in error
 107           messages; hence, a partition-dependent object should have one
 108           primary partition dependency and one or more secondary partition
 109           dependencies. Note that partition dependencies are made in
 110           addition to, not instead of, any dependencies the object would
 111           normally have. This simplifies ATTACH/DETACH PARTITION
 112           operations: the partition dependencies need only be added or
 113           removed. Example: a child partitioned index is made
 114           partition-dependent on both the partition table it is on and the
 115           parent partitioned index, so that it goes away if either of
 116           those is dropped, but not otherwise. The dependency on the
 117           parent index is primary, so that if the user tries to drop the
 118           child partitioned index, the error message will suggest dropping
 119           the parent index instead (not the table).
 120
 121    DEPENDENCY_EXTENSION (e)
 122           The dependent object is a member of the extension that is the
 123           referenced object (see pg_extension). The dependent object can
 124           be dropped only via DROP EXTENSION on the referenced object.
 125           Functionally this dependency type acts the same as an INTERNAL
 126           dependency, but it's kept separate for clarity and to simplify
 127           pg_dump.
 128
 129    DEPENDENCY_AUTO_EXTENSION (x)
 130           The dependent object is not a member of the extension that is
 131           the referenced object (and so it should not be ignored by
 132           pg_dump), but it cannot function without the extension and
 133           should be auto-dropped if the extension is. The dependent object
 134           may be dropped on its own as well. Functionally this dependency
 135           type acts the same as an AUTO dependency, but it's kept separate
 136           for clarity and to simplify pg_dump.
 137
 138    Other dependency flavors might be needed in future.
 139
 140    Note that it's quite possible for two objects to be linked by more than
 141    one pg_depend entry. For example, a child partitioned index would have
 142    both a partition-type dependency on its associated partition table, and
 143    an auto dependency on each column of that table that it indexes. This
 144    sort of situation expresses the union of multiple dependency semantics.
 145    A dependent object can be dropped without CASCADE if any of its
 146    dependencies satisfies its condition for automatic dropping.
 147    Conversely, all the dependencies' restrictions about which objects must
 148    be dropped together must be satisfied.
 149
 150    Most objects created during initdb are considered “pinned”, which means
 151    that the system itself depends on them. Therefore, they are never
 152    allowed to be dropped. Also, knowing that pinned objects will not be
 153    dropped, the dependency mechanism doesn't bother to make pg_depend
 154    entries showing dependencies on them. Thus, for example, a table column
 155    of type numeric notionally has a NORMAL dependency on the numeric data
 156    type, but no such entry actually appears in pg_depend.