Seguimiento de dependencias de Postgresql

Cuando crea estructuras de base de datos complejas que involucran muchas tablas con key restricciones, vistas, activadores, funciones, etc. implícitamente crea una red de dependencias entre los objetos. Por ejemplo, una mesa con un extranjero key la restricción depende de la tabla a la que hace referencia.

Para garantizar la integridad de toda la estructura de la base de datos, PostgreSQL se asegura de que no pueda descartar objetos de los que todavía dependen otros objetos. Por ejemplo, intentar eliminar la tabla de productos que consideramos en la Sección 5.4.5, con la tabla de pedidos dependiendo de ella, daría como resultado un mensaje de error como este:

DROP TABLE products;

ERROR:  cannot drop table products because other objects depend on it
DETAIL:  constraint orders_product_no_fkey on table orders depends on table products
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

El mensaje de error contiene una sugerencia útil: si no desea molestarse en eliminar todos los objetos dependientes individualmente, puede ejecutar:

DROP TABLE products CASCADE;

y todos los objetos dependientes se eliminarán, al igual que cualquier objeto que dependa de ellos, recursivamente. En este caso, no elimina la tabla de pedidos, solo elimina el extranjero key restricción. Se detiene allí porque nada depende del extranjero. key restricción. (Si quieres comprobar qué DROP ... CASCADE lo hare, corre DROP sin CASCADE y lee el DETAIL producción.)

Casi todos DROP comandos en el soporte de PostgreSQL especificando CASCADE. Por supuesto, la naturaleza de las posibles dependencias varía según el tipo de objeto. También puedes escribir RESTRICT en lugar de CASCADE para obtener el comportamiento predeterminado, que es evitar que se suelten objetos de los que dependan otros objetos.

Nota

De acuerdo con el estándar SQL, especificar ya sea RESTRICT o CASCADE se requiere en un DROP mando. En realidad, ningún sistema de base de datos impone esa regla, pero si el comportamiento predeterminado es RESTRICT o CASCADE varía a través de los sistemas.

si un DROP el comando enumera múltiples objetos, CASCADE solo se requiere cuando hay dependencias fuera del grupo especificado. Por ejemplo, al decir DROP TABLE tab1, tab2 la existencia de un extranjero key referenciando tab1 desde tab2 no significaría eso CASCADE se necesita para tener éxito.

Para las funciones definidas por el usuario, PostgreSQL rastrea las dependencias asociadas con las propiedades visibles externamente de una función, como sus argumentos y tipos de resultados, pero no dependencias que solo podrían conocerse examinando el cuerpo de la función. Como ejemplo, considere esta situación:

CREATETYPE rainbow ASENUM('red','orange','yellow','green','blue','purple');CREATETABLE my_colors (color rainbow, note text);CREATEFUNCTION get_color_note (rainbow)RETURNStextAS'SELECT note FROM my_colors WHERE color = $1'LANGUAGESQL;

(Ver Sección 37.5 para obtener una explicación de las funciones del lenguaje SQL). PostgreSQL será consciente de que el get_color_note función depende de la rainbow tipo: descartar el tipo obligaría a descartar la función, porque su tipo de argumento ya no estaría definido. Pero PostgreSQL no considerará get_color_note depender de la my_colors tabla, por lo que no eliminará la función si se descarta la tabla. Si bien hay desventajas en este enfoque, también hay beneficios. La función sigue siendo válida en cierto sentido si falta la tabla, aunque ejecutarla provocaría un error; crear una nueva tabla con el mismo nombre permitiría que la función volviera a funcionar.