pg_depend

PostgreSQL 9.1.23 Documentation
Prev | Up | Chapter 45. System Catalogs | Next

# 45.18. `pg_depend`

The catalog `pg_depend` records the dependency relationships between database objects. This information allows `DROP` commands to find which other objects must be dropped by `DROP CASCADE` or prevent dropping in the `DROP RESTRICT` case.

See also `pg_shdepend`, which performs a similar function for dependencies involving objects that are shared across a database cluster.

Table 45-18. `pg_depend` Columns

Name | Type | References | Description
--- | --- | --- | ---
`classid` | `oid` | ``pg_class`.oid` | The OID of the system catalog the dependent object is in
`objid` | `oid` | any OID column | The OID of the specific dependent object
`objsubid` | `int4` |  | For a table column, this is the column number (the `objid` and `classid` refer to the table itself). For all other object types, this column is zero.
`refclassid` | `oid` | ``pg_class`.oid` | The OID of the system catalog the referenced object is in
`refobjid` | `oid` | any OID column | The OID of the specific referenced object
`refobjsubid` | `int4` |  | For a table column, this is the column number (the `refobjid` and `refclassid` refer to the table itself). For all other object types, this column is zero.
`deptype` | `char` |  | A code defining the specific semantics of this dependency relationship; see text

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

`DEPENDENCY_NORMAL` (`n`)

  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 `CASCADE`, in which case the dependent object is dropped, too. Example: a table column has a normal dependency on its data type.

`DEPENDENCY_AUTO` (`a`)

  The dependent object can be dropped separately from the referenced object, and should be automatically dropped (regardless of `RESTRICT` or `CASCADE` mode) if the referenced object is dropped. Example: a named constraint on a table is made autodependent on the table, so that it will go away if the table is dropped.

`DEPENDENCY_INTERNAL` (`i`)

  The dependent object was created as part of creation of the referenced object, and is really just a part of its internal implementation. A `DROP` of the dependent object will be disallowed outright (we'll tell the user to issue a `DROP` against the referenced object, instead). A `DROP` of the referenced object will be propagated through to drop the dependent object whether `CASCADE` is specified or not. Example: a trigger that's created to enforce a foreign-key constraint is made internally dependent on the constraint's `pg_constraint` entry.

`DEPENDENCY_EXTENSION` (`e`)

  The dependent object is a member of the extension that is the referenced object (see `pg_extension`). The dependent object can be dropped only via `DROP EXTENSION` on the referenced object. Functionally this dependency type acts the same as an internal dependency, but it's kept separate for clarity and to simplify pg_dump.

`DEPENDENCY_PIN` (`p`)

  There is no dependent object; this type of entry is a signal that the system itself depends on the referenced object, and so that object must never be deleted. Entries of this type are created only by `initdb`. The columns for the dependent object contain zeroes.

Other dependency flavors might be needed in future.

Prev | Home | Next
`pg_default_acl` | Up | `pg_description`