pg_depend

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

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

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

Большинство объектов, созданных во время initdb, считаются "прикрепленными", что означает, что система сама зависит от них. Поэтому их никогда нельзя сбрасывать. Также, зная, что "прикрепленные" объекты не будут отброшены, механизм зависимостей не утруждает себя созданием записей pg_depend, показывающих зависимости от них. Так, например, столбец таблицы типа numeric условно имеет зависимость NORMAL от типа данных numeric, но в действительности такой записи в pg_depend нет.