5.13. Dependency Tracking
5.13.依赖性跟踪
When you create complex database structures involving many tables with foreign key constraints,views, triggers, functions, etc. you implicitly create a net of dependencies between the objects. For instance, a table with a foreign key constraint depends on the table it references.
当创建了一个复杂的数据库架构，里面包含许多有外键约束的表，视图，触发器，函数等等，实际上，你隐式的在各个对象之间创建了一个依赖网。例如，具有外键约束的表依赖于它所引用的表。
To ensure the integrity of the entire database structure, PostgreSQL makes sure that you cannot drop objects that other objects still depend on. For example, attempting to drop the products table we considered in Section 5.3.5, with the orders table depending on it, would result in an error message like this:
为确保整个数据库架构的完整性，PostgreSQL确保不能删掉被其他对象依赖的对象。例如，尝试删除我们在5.3.5节提到的products表，因为orders表依赖于它，那么删除的时候会报错：
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.
The error message contains a useful hint: if you do not want to bother deleting all the dependent objects individually, you can run:
错误信息中有一个很有用的提示： 如果您不想麻烦地删除所有依赖对象，则可以运行：
DROP TABLE products CASCADE;
and all the dependent objects will be removed, as will any objects that depend on them, recursively.In this case, it doesn't remove the orders table, it only removes the foreign key constraint. It stops there because nothing depends on the foreign key constraint. (If you want to check what DROP ... CASCADE will do, run DROP without CASCADE and read the DETAIL output.)
那么相关的依赖对象也会被删掉，以及依赖于这些对象的对象，也会递归的删掉。上例语句，不会删掉orders表，只会删掉它上面的外键约束。删掉外键约束后就结束了，因为没有对象依赖于此外键约束。（如果想检查下DROP...CASCADE要做什么，那么不要加CASCADE运行DROP命令，然后看下详细输出即可。）
Almost all DROP commands in PostgreSQL support specifying CASCADE. Of course, the nature of the possible dependencies varies with the type of the object. You can also write RESTRICT instead of CASCADE to get the default behavior, which is to prevent dropping objects that any other objects depend on.
PostgreSQL中几乎所有的DROP命令都支持CASCADE选项。 当然，可能的依赖关系的性质随对象的类型而变化。也可以编写RESTRICT而不是CASCADE来获取默认行为，这可以防止删掉任何其他对象所依赖的对象。
Note
注
According to the SQL standard, specifying either RESTRICT or CASCADE is required in a DROP command. No database system actually enforces that rule, but whether the default behavior is RESTRICT or CASCADE varies across systems.
根据SQL标准，在DROP命令中，需要指定RESTRICT或者CASCADE。但实际上，没有数据库系统强制执行此规则，但是默认行为是RESTRICT还是CASCADE，在不同系统会有所不同。
If a DROP command lists multiple objects, CASCADE is only required when there are dependencies outside the specified group. For example, when saying DROP TABLE tab1, tab2 the existence of a foreign key referencing tab1 from tab2 would not mean that CASCADE is needed to succeed.
当使用DROP命令同时删除多个对象时， 则仅当在指定组之外存在依赖项时才需要CASCADE。 例如，当执行DROP TABLE tab1，tab2时，存在引用来自tab2的tab1的外键并不意味着需要CASCADE才能成功。
测试：
For user-defined functions, PostgreSQL tracks dependencies associated with a function's externally-visible properties, such as its argument and result types, but not dependencies that could only be known by examining the function body. As an example, consider this situation:
对于用户自定义函数，PostgreSQL跟踪与函数的外部可见属性（例如，其参数和结果类型）相关的依赖关系，但不是只能通过检查函数体才能知道的依赖关系。 例如，考虑下列情况：
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow','green', 'blue', 'purple');
CREATE TABLE my_colors (color rainbow, note text);
CREATE FUNCTION get_color_note (rainbow) RETURNS text AS
'SELECT note FROM my_colors WHERE color = $1'
LANGUAGE SQL;
(See Section 38.5 for an explanation of SQL-language functions.) PostgreSQL will be aware that the get_color_note function depends on the rainbow type: dropping the type would force dropping the function, because its argument type would no longer be defined. But PostgreSQL will not consider get_color_note to depend on the my_colors table, and so will not drop the function if the table is dropped. While there are disadvantages to this approach, there are also benefits. The function is still valid in some sense if the table is missing, though executing it would cause an error; creating a new table of the same name would allow the function to work again.
（有关SQL语言中函数的解释，请参考38.5节）PostgreSQL会知道函数 get_color_note依赖于rainbow类型：删除该类型会强制删除该函数，因为该函数的参数类型无法再定义。但PostgreSQL却不知道get_color_note依赖于表my_colors，所以删除这个表就不会删除该函数。这种方法虽然有缺点，但也有好处。如果删除该表，该函数在某种意义上仍然有效，尽管执行该函数会报错，但再创建一个同名的新表，该函数就能够再次可用了。
来源：CSDN
作者：丹心明月
链接：https://blog.csdn.net/ghostliming/article/details/104519849