O catálogo pg_depend registra os
relacionamentos de dependência entre objetos de banco de dados.
Esta informação permite que os comandos DROP
descubram quais outros objetos devem ser excluídos por
DROP CASCADE, ou evitem a exclusão no caso
DROP RESTRICT.
Veja também pg_shdepend, que executa uma função semelhante para dependências envolvendo objetos compartilhados em uma instância de banco de dados.
Tabela 52.18. Colunas de pg_depend
Coluna Tipo de dados Descrição |
|---|
OID do catálogo do sistema em que o objeto dependente se encontra |
OID do objeto dependente específico |
Para uma coluna de tabela, este é o número da coluna
( |
OID do catálogo do sistema em que o objeto referenciado se encontra |
OID do objeto referenciado específico |
Para uma coluna de tabela, este é o número da coluna
(o |
Um código que define a semântica específica dessa relação de dependência; veja o texto |
Em todos os casos, uma entrada de
pg_depend indica que o objeto
referenciado não pode ser excluído sem também excluir o objeto
dependente.
Entretanto, existem várias sutilezas identificadas por
deptype:
DEPENDENCY_NORMAL (n)
Um relacionamento normal entre objetos criados separadamente.
O objeto dependente pode ser excluído sem afetar o objeto referenciado.
O objeto referenciado só pode ser excluído especificando
CASCADE, caso em que o objeto dependente
também é excluído.
Exemplo: uma coluna de tabela possui uma dependência normal
de seu tipo de dados.
DEPENDENCY_AUTO (a)
O objeto dependente pode ser excluído separadamente do objeto
referenciado, devendo ser excluído automaticamente
(independentemente do modo RESTRICT ou
CASCADE) se o objeto referenciado for excluído.
Exemplo: uma restrição com nome em uma tabela torna-se
autodependente da tabela, de modo que irá desaparecer se
a tabela for excluída.
DEPENDENCY_INTERNAL (i)
O objeto dependente foi criado como parte da criação do objeto
referenciado, sendo, na verdade, apenas uma parte de sua
implementação interna.
Um DROP direto no objeto dependente será
totalmente proibido (será dito ao usuário para emitir um comando
DROP contra o objeto referenciado, em vez disso).
Um DROP do objeto referenciado resultará na
exclusão automática do objeto dependente, independentemente de
CASCADE ser especificado ou não.
Se o objeto dependente tiver que ser excluído devido a uma
dependência de algum outro objeto sendo excluído, sua exclusão
será convertida em uma exclusão do objeto referenciado, para que
as dependências NORMAL e AUTO
do objeto dependente se comportem como se fossem dependências
do objeto referenciado.
Exemplo: a regra ON SELECT de uma visão
torna-se internamente dependente da visão, evitando que
seja excluída enquanto a visão permanece.
As dependências da regra (como as tabelas às quais ela se refere)
agem como se fossem dependências da visão.
DEPENDENCY_PARTITION_PRI (P)DEPENDENCY_PARTITION_SEC (S)
O objeto dependente foi criado como parte da criação do objeto
referenciado, sendo, na verdade, apenas uma parte de sua
implementação interna; entretanto, diferentemente de
INTERNAL, existe mais de um objeto referenciado.
O objeto dependente não deve ser excluído, a menos que pelo menos
um desses objetos referenciados seja excluído; se houver,
o objeto dependente deverá ser excluído, independentemente de
CASCADE ser especificado ou não.
Também diferentemente de INTERNAL, a exclusão
de algum outro objeto do qual o objeto dependente depende não
resulta na exclusão automática de qualquer objeto referenciado
por partição.
Portanto, se a exclusão não for transmitida em cascata para pelo
menos um desses objetos por algum outro caminho, ela será recusada.
(Geralmente, o objeto dependente compartilha todas as
suas dependências não particionadas com pelo menos um objeto
referenciado por partição, de modo que esta restrição não resulte
no bloqueio de qualquer exclusão em cascata.)
As dependências de partição primária e secundária comportam-se
de forma idêntica, exceto que a dependência primária é preferida
para uso em mensagens de erro; portanto, um objeto dependente de
partição deve ter uma dependência de partição primária e uma ou
mais dependências de partição secundária.
Note que as dependências de partição são feitas além, e não em
vez de, de quaisquer dependências que o objeto normalmente teria.
Isto simplifica as operações de
ATTACH/DETACH PARTITION: as dependências de
partição só precisam ser adicionadas ou removidas.
Exemplo: um índice particionado filho torna-se dependente da
partição tanto da tabela de partição em que está quanto do índice
particionado pai, de modo que ele irá desaparecer se algum deles
for excluído, mas não de outra forma.
A dependência do índice pai é primária, de modo que, se o usuário
tentar excluir o índice particionado filho, a mensagem de erro
irá sugerir a exclusão do índice pai (e não da tabela).
DEPENDENCY_EXTENSION (e)
O objeto dependente é membro da extensão
que é o objeto referenciado
(veja pg_extension).
O objeto dependente pode ser excluído somente via
DROP EXTENSION no objeto referenciado.
Funcionalmente, este tipo de dependência age da mesma forma que
uma dependência INTERNAL, mas é mantida
em separado para maior clareza, e para simplificar o
pg_dump.
DEPENDENCY_AUTO_EXTENSION (x)
O objeto dependente não é membro da extensão que é o objeto
referenciado (e, portanto, não deve ser ignorado por
pg_dump), mas não pode funcionar sem a
extensão, devendo ser excluído automaticamente se a extensão o for.
O objeto dependente também pode ser excluído sozinho.
Funcionalmente, este tipo de dependência age da mesma forma que
uma dependência AUTO, mas é mantida em
separado para maior clareza, e para simplificar o
pg_dump.
Podem ser necessários outros tipos de dependência no futuro.
Note-se ser bem possível que dois objetos sejam vinculados por mais
de uma entrada de pg_depend.
Por exemplo, um índice particionado filho teria uma dependência do
tipo partição em sua tabela de partição associada, e uma dependência
automática em cada coluna da tabela que ele indexa.
Este tipo de situação expressa a união de semânticas de múltiplas
dependências.
Um objeto dependente poderá ser excluído sem CASCADE
se alguma de suas dependências satisfizer sua condição de exclusão
automática.
Por outro lado, todas as restrições de dependências sobre quais
objetos devem ser excluídos juntos devem ser satisfeitas.
A maioria dos objetos criados durante o
initdb são considerados
“fixados” (pinned),
significando que o próprio sistema depende deles.
Portanto, nunca é permitido que sejam excluídos.
Além disso, sabendo que objetos fixados não serão excluídos,
p mecanismo de dependência não se preocupa em criar entradas na tabela
pg_depend que mostrem dependências
em relação a eles.
Assim, por exemplo, uma coluna de tabela do tipo de dados
numeric tem, conceitualmente, uma dependência
NORMAL em relação ao tipo de dados
numeric, mas na verdade esta entrada não aparece na
tabela pg_depend.