52.18. pg_depend #

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

classid oid (referencia pg_class.oid)

OID do catálogo do sistema em que o objeto dependente se encontra

objid oid (referencia qualquer coluna OID)

OID do objeto dependente específico

objsubid int4

Para uma coluna de tabela, este é o número da coluna (objid e classid fazem referência à própria tabela). Para todos os outros tipos de objeto, o valor dessa coluna é zero.

refclassid oid (referencia pg_class.oid)

OID do catálogo do sistema em que o objeto referenciado se encontra

refobjid oid (referencia qualquer coluna OID)

OID do objeto referenciado específico

refobjsubid int4

Para uma coluna de tabela, este é o número da coluna (o refobjid e refclassid referem-se à própria tabela). Para todos os outros tipos de objeto, o valor dessa coluna é zero.

deptype char

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.

52.18.1. Veja também #