51.18. pg_depend
#
В каталоге pg_depend
записываются отношения зависимости между объектами базы данных. Благодаря этой информации, команды DROP
могут найти, какие объекты должны удаляться при использовании DROP CASCADE
, или когда нужно запрещать удаление при DROP RESTRICT
.
Также смотрите описание каталога pg_shdepend
, который играет подобную роль в отношении совместно используемых объектов в кластере баз данных.
Таблица 51.18. Столбцы pg_depend
Тип столбца Описание |
---|
OID системного каталога, в котором находится зависимый объект |
OID определённого зависимого объекта |
Для столбца таблицы это номер столбца ( |
OID системного каталога, в котором находится вышестоящий объект |
OID определённого вышестоящего объекта |
Для столбца таблицы это номер столбца ( |
Код, определяющий конкретную семантику данного отношения зависимости; см. текст |
Во всех случаях, запись в pg_depend
показывает, что вышестоящий объект нельзя удалить, не удаляя подчинённый объект. Однако есть несколько подвидов зависимости, задаваемых в поле deptype
:
DEPENDENCY_NORMAL
(n
)Обычное отношение между отдельно создаваемыми объектами. Подчинённый объект можно удалить, не затрагивая вышестоящий объект. Вышестоящий объект можно удалить только с указанием
CASCADE
, при этом будет удалён и подчинённый объект. Например, столбец таблицы находится в обычной зависимости от своего типа данных.DEPENDENCY_AUTO
(a
)Подчинённый объект может быть удалён отдельно от вышестоящего и должен быть удалён автоматически (вне зависимости от указаний
RESTRICT
иCASCADE
), если удаляется вышестоящий объект. Например, именованное ограничение для таблицы находится в автоматической зависимости от таблицы, так что оно исчезнет при удалении таблицы.DEPENDENCY_INTERNAL
(i
)Подчинённый объект был создан в процессе создания вышестоящего и на самом деле является только частью его внутренней реализации. Для такого объекта будет запрещена команда
DROP
(мы подскажем пользователю, что вместо этого надо выполнитьDROP
для вышестоящего объекта). ДействиеDROP
для вышестоящего объекта будет автоматически распространено и на этот подчинённый объект, вне зависимости от присутствия указанияCASCADE
. Если подчинённый объект должен быть удалён вследствие зависимости от какого-то другого удаляемого объекта, удаление подчинённого преобразуется в удаление вышестоящего, то есть зависимостиNORMAL
иAUTO
подчинённого объекта во многом действуют как зависимости вышестоящего объекта. Например, правилоON SELECT
для представления автоматически становится внутренне зависимым от этого представления, что не позволяет удалить это правило, пока существует представление. Зависимости этого правила (например, от таблиц, которые в нём фигурируют) будут действовать так же, как если бы они были зависимостями самого представления.DEPENDENCY_PARTITION_PRI
(P
)DEPENDENCY_PARTITION_SEC
(S
)Подчинённый объект (секция) был создан в процессе создания вышестоящего (секционированного отношения) и на самом деле является только частью его внутренней реализации; однако у него есть несколько вышестоящих объектов, что отличает эту зависимость от
INTERNAL
. Такой подчинённый объект должен удаляться только тогда, когда удаляется хотя бы один из этих вышестоящих объектов; в этом случае не должно иметь значения наличие указанияCASCADE
. Также с такой зависимостью, в отличие отINTERNAL
, попытка удаления некоторого другого объекта, от которого зависит подчинённый, не приводит к автоматическому удалению какого-либо из связанных секционированных отношений. Таким образом, если удаление не доходит до минимум одного из вышестоящих объектов по какому-то пути, оно не будет произведено. (В большинстве случаев подчинённый объект разделяет все свои несекционные зависимости с минимум одним секционно-связанным объектом, чтобы это ограничение не блокировало каскадные удаления.) Первичные (PRI) и вторичные (SEC) секционные зависимости похожи, и отличаются только тем, что первичные зависимости предпочитаются при формировании сообщений об ошибках; поэтому секционно-подчинённый объект, как правило, будет иметь одну первичную секционную зависимость и одну или несколько вторичных. Заметьте, что секционные зависимости создаются в дополнение, но не вместо обычных зависимостей, которые будет иметь объект. Это упрощает операцииATTACH/DETACH PARTITION
: они будут просто добавлять или удалять секционные зависимости. Например, дочерний секционированный индекс оказывается секционно-зависимым и от собственной секционированной таблицы, и от родительского секционированного индекса, так что он будет удалён при удалении одного из этих объектов, но не в других случаях. Зависимость от родительского секционированного индекса является первичной, поэтому если пользователь пытается удалить дочерний секционированный индекс, в сообщении об ошибке будет предложено удалить родительский индекс (а не таблицу).DEPENDENCY_EXTENSION
(e
)Подчинённый объект входит в состав расширения, которое является вышестоящим объектом (см.
pg_extension
). Удалить подчинённый объект можно, только выполнив командуDROP EXTENSION
для вышестоящего объекта. Функционально этот тип зависимости действует так же, как и внутренняя (INTERNAL
) зависимость, но он выделен для наглядности и упрощения pg_dump.DEPENDENCY_AUTO_EXTENSION
(x
)Подчинённый объект не входит в состав расширения, являющегося вышестоящим объектом (и поэтому он не должен игнорироваться программой pg_dump), но он не может функционировать без расширения и должен удаляться автоматически при удалении расширения. Такой объект также может быть удалён сам по себе. Функционально эта зависимость работает как зависимость
AUTO
, но она выделена для наглядности и упрощения pg_dump.
В будущем могут появиться и другие подвиды зависимости.
Заметьте, что два объекта вполне могут быть связаны между собой более чем одной записью в pg_depend
. Например, дочерний секционированный индекс будет иметь и зависимость секционного типа от связанной секционированной таблицы, и автоматическую зависимость от каждого столбца таблицы, входящего в индекс. В подобных ситуациях имеет место совмещение зависимостей, несущих разных смысл. И если какая-либо из зависимостей удовлетворяет условиям для автоматического удаления, подчинённый объект может быть удалён без указания CASCADE
. При этом, конечно, должны быть удовлетворены все ограничения зависимостей, определяющих подлежащие удалению объекты.
Большинство объектов, созданных во время работы initdb, считаются «закреплёнными», что означает, что сама система зависит от них. Поэтому их нельзя удалять ни при каких условиях. Кроме того, зная, что закреплённые объекты не будут удалены, механизм зависимостей не создаёт в pg_depend
записи, показывающие зависимости от этих объектов. Так, например, столбец таблицы типа numeric
условно имеет зависимость NORMAL
от типа данных numeric
, но на самом деле такая запись не появляется в pg_depend
.