Catálogos de Postgresql: ejemplo de pg_depend

El catalogo pg_depend registra las relaciones de dependencia entre los objetos de la base de datos. Esta información permite DROP comandos para encontrar qué otros objetos deben ser eliminados DROP CASCADE o evitar que se caiga en el DROP RESTRICT caso.

Ver también pg_shdepend, que realiza una función similar para las dependencias que involucran objetos que se comparten en un clúster de base de datos.

Tabla 51.18. pg_depend Columnas

En todos los casos, un pg_depend La entrada indica que el objeto al que se hace referencia no se puede eliminar sin eliminar también el objeto dependiente. Sin embargo, hay varios subsabores identificados por deptype:

DEPENDENCY_NORMAL (n)

Una relación normal entre objetos creados por separado. El objeto dependiente se puede eliminar sin afectar al objeto referenciado. El objeto al que se hace referencia solo se puede eliminar especificando CASCADE, en cuyo caso el objeto dependiente también se descarta. Ejemplo: una columna de la tabla tiene una dependencia normal de su tipo de datos.

DEPENDENCY_AUTO (a)

El objeto dependiente se puede eliminar por separado del objeto referenciado y debe eliminarse automáticamente (independientemente de RESTRICT o CASCADE modo) si el objeto referenciado se descarta. Ejemplo: una restricción con nombre en una tabla se hace autodependiente de la tabla, por lo que desaparecerá si se descarta la tabla.

DEPENDENCY_INTERNAL (i)

El objeto dependiente se creó como parte de la creación del objeto referenciado y, en realidad, es solo una parte de su implementación interna. Directo DROP del objeto dependiente será rechazado por completo (le diremos al usuario que emita un DROP contra el objeto referenciado, en su lugar). A DROP del objeto referenciado dará como resultado la eliminación automática del objeto dependiente si CASCADE se especifica o no. Si el objeto dependiente debe eliminarse debido a una dependencia de algún otro objeto que se está eliminando, su eliminación se convierte en una eliminación del objeto referenciado, de modo que NORMAL y AUTO las dependencias del objeto dependiente se comportan como si fueran dependencias del objeto referenciado. Ejemplo: una vista ON SELECT La regla se hace internamente dependiente de la vista, lo que evita que se elimine mientras la vista permanece. Las dependencias de la regla (como las tablas a las que hace referencia) actúan como si fueran dependencias de la vista.

DEPENDENCY_PARTITION_PRI (P)DEPENDENCY_PARTITION_SEC (S)

El objeto dependiente se creó como parte de la creación del objeto referenciado, y en realidad es solo una parte de su implementación interna; sin embargo, a diferencia de INTERNAL, hay más de uno de esos objetos referenciados. El objeto dependiente no debe descartarse a menos que se descarte al menos uno de estos objetos referenciados; si alguno lo es, el objeto dependiente debe descartarse independientemente de que CASCADE está especificado. También a diferencia de INTERNAL, una caída de algún otro objeto del que depende el objeto dependiente no da como resultado la eliminación automática de ningún objeto referenciado a la partición. Por lo tanto, si la caída no cae en cascada a al menos uno de estos objetos a través de alguna otra ruta, será rechazada. (En la mayoría de los casos, el objeto dependiente comparte todas sus dependencias que no son de partición con al menos un objeto referenciado a partición, de modo que esta restricción no da como resultado el bloqueo de ninguna eliminación en cascada). Las dependencias de partición primaria y secundaria se comportan de manera idéntica excepto que la dependencia primaria se prefiere para su uso en mensajes de error; por lo tanto, un objeto dependiente de la partición debe tener una dependencia de partición primaria y una o más dependencias de partición secundaria. Tenga en cuenta que las dependencias de las particiones se realizan además, no en lugar de, las dependencias que el objeto tendría normalmente. Esto simplifica ATTACH/DETACH PARTITION operaciones: las dependencias de la partición solo necesitan agregarse o eliminarse. Ejemplo: un índice particionado secundario se hace dependiente de la partición tanto de la tabla de particiones en la que se encuentra como del índice particionado principal, de modo que desaparece si alguno de ellos se elimina, pero no de otra manera. La dependencia del índice principal es primaria, de modo que si el usuario intenta eliminar el índice particionado secundario, el mensaje de error sugerirá eliminar el índice principal (no la tabla).

DEPENDENCY_EXTENSION (e)

El objeto dependiente es miembro de la extensión ese es el objeto referenciado (ver pg_extension). El objeto dependiente solo se puede quitar mediante DROP EXTENSION en el objeto referenciado. Funcionalmente, este tipo de dependencia actúa igual que un INTERNAL dependencia, pero se mantiene separado para mayor claridad y para simplificar pg_dump.

DEPENDENCY_AUTO_EXTENSION (x)

El objeto dependiente no es miembro de la extensión que es el objeto referenciado (por lo que pg_dump no debe ignorarlo), pero no puede funcionar sin la extensión y debe descartarse automáticamente si la extensión lo es. El objeto dependiente también puede descartarse por sí solo. Funcionalmente, este tipo de dependencia actúa igual que un AUTO dependencia, pero se mantiene separado para mayor claridad y para simplificar pg_dump.

DEPENDENCY_PIN (p)

No hay ningún objeto dependiente; este tipo de entrada es una señal de que el sistema en sí depende del objeto referenciado y, por lo tanto, ese objeto nunca debe eliminarse. Las entradas de este tipo son creadas solo por initdb. Las columnas del objeto dependiente contienen ceros.

Es posible que en el futuro se necesiten otros tipos de dependencia.

Tenga en cuenta que es muy posible que dos objetos estén vinculados por más de una pg_depend entrada. Por ejemplo, un índice particionado secundario tendría una dependencia de tipo de partición en su tabla de partición asociada y una dependencia automática en cada columna de esa tabla que indexa. Este tipo de situación expresa la unión de semánticas de dependencia múltiple. Un objeto dependiente se puede eliminar sin CASCADE si alguna de sus dependencias satisface su condición de descarte automático. Por el contrario, se deben satisfacer todas las restricciones de las dependencias sobre qué objetos deben descartarse juntos.