51.18. pg_depend#

51.18. pg_depend
51.18. pg_depend
Назад НаверхГлава 51. Системные каталогиНачало Далее

51.18. pg_depend

Каталог pg_depend записывает зависимости между объектами базы данных. Эта информация позволяет командам DROP найти другие объекты, которые должны быть удалены с помощью DROP CASCADE или предотвратить удаление в случае DROP RESTRICT.

См. также pg_shdepend, который выполняет аналогичную функцию для зависимостей, связанных с объектами, которые являются общими для кластера базы данных.

Таблица 51.18. pg_depend Столбцы

Тип столбца

Описание

classid oid (ссылается на pg_class.oid)

OID системного каталога, в котором находится зависимый объект

objid oid (ссылается на любой столбец OID)

OID конкретного зависимого объекта

objsubid int4

Для столбца таблицы это номер столбца (поля objid и classid относятся к самой таблице). Для всех остальных типов объектов этот столбец равен нулю.

refclassid oid (ссылается на pg_class.oid)

OID системного каталога, в котором находится ссылочный объект.

refobjid oid (ссылается на любой столбец типа OID)

OID указанного объекта

refobjsubid int4

Для столбца таблицы это номер столбца (поля refobjid и refclassid относятся к самой таблице). Для всех остальных типов объектов этот столбец равен нулю.

deptype char

Код, определяющий конкретную семантику этой зависимостной связи; см. текст


Во всех случаях запись pg_depend указывает на то, что ссылочный объект нельзя удалить без удаления зависимого объекта. Однако существует несколько подтипов, определенных полем deptype:

DEPENDENCY_NORMAL (n)

Обычное отношение между отдельно созданными объектами. Зависимый объект может быть удален без влияния на ссылочный объект. Ссылочный объект может быть удален только при указании CASCADE, в этом случае также будет удален зависимый объект. Пример: столбец таблицы имеет обычную зависимость от своего типа данных.

DEPENDENCY_AUTO (a)

Зависимый объект может быть удален отдельно от ссылочного объекта и должен быть автоматически удален (независимо от режима RESTRICT или CASCADE) в случае удаления ссылочного объекта. Пример: именованное ограничение на таблицу становится автоматически зависимым от таблицы, так что оно будет удалено, если таблица будет удалена.

DEPENDENCY_INTERNAL (i)

Зависимый объект был создан вместе с созданием ссылочного объекта и на самом деле является только частью его внутренней реализации. Прямое удаление DROP зависимого объекта будет полностью запрещено (мы скажем пользователю выполнить команду DROP для ссылочного объекта вместо этого). Удаление ссылочного объекта приведет к автоматическому удалению зависимого объекта, независимо от того, указано ли CASCADE или нет. Если зависимый объект должен быть удален из-за зависимости от удаленного другого объекта, его удаление преобразуется в удаление ссылочного объекта, так что NORMAL и AUTO зависимости зависимого объекта ведут себя так же, как если бы они были зависимостями ссылочного объекта. Пример: правило ON SELECT представления становится внутренне зависимым от представления, предотвращая его удаление, пока представление существует. Зависимости правила (например, таблицы, на которые оно ссылается) ведут себя так, как если бы они были зависимостями представления.

DEPENDENCY_PARTITION_PRI (P)
DEPENDENCY_PARTITION_SEC (S)

Объект, зависимый от другого объекта, создается вместе с созданием ссылочного объекта и на самом деле является только частью его внутренней реализации; однако, в отличие от INTERNAL, таких ссылочных объектов может быть несколько. Объект, зависимый от другого, не может быть удален, если не удален хотя бы один из этих ссылочных объектов; если хотя бы один из них удален, объект, зависимый от другого, должен быть удален, независимо от того, указано ли CASCADE. Также, в отличие от INTERNAL, удаление какого-либо другого объекта, от которого зависит объект, зависимый от другого, не приводит к автоматическому удалению какого-либо объекта, ссылающегося на раздел. Поэтому, если удаление не распространяется хотя бы на один из этих объектов по другому пути, оно будет отклонено. (В большинстве случаев, объект, зависимый от другого, имеет все свои зависимости, кроме раздела, с хотя бы одним объектом, ссылающимся на раздел, так что это ограничение не приводит к блокировке какого-либо каскадного удаления). Зависимости от основного и вторичного секций ведут себя одинаково, за исключением того, что основная зависимость предпочтительна для использования в сообщениях об ошибках; поэтому объект, зависимый от раздела, должен иметь одну основную зависимость от раздела и одну или несколько вторичных зависимостей от раздела. Обратите внимание, что зависимости от секций создаются дополнительно к зависимостям, которые объект обычно имеет. Это упрощает операции 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.

Назад Наверх Далее
51.17. pg_default_acl Начало 51.19. pg_description