当我们创建一个涉及到很多具有外键约束、视图、触发器、函数等的表的复杂数据库结构时,我们隐式地创建了一张对象之间的依赖关系网。例如,具有一个外键约束的表依赖于它所引用的表。
为了保证整个数据库结构的完整性,PostgreSQL确保我们无法删除仍然被其他对象依赖的对象。例如,尝试删除第 5.4.5 外键中的产品表会导致一个如下的错误消息,因为有订单表依赖于产品表:
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.
该错误消息包含了一个有用的提示:如果我们不想一个一个去删除所有的依赖对象,我们可以执行:
DROP TABLE products CASCADE;
这样所有的依赖对象将被移除,同样依赖于它们的任何对象也会被递归删除。在这种情况下,订单表不会被移除,但是它的外键约束会被移除。之所以在这里会停下,是因为没有什么依赖着外键约束(如果希望检查DROP ... CASCADE
会干什么,运行不带CASCADE
的DROP
并阅读DETAIL
输出)。
PostgreSQL中的几乎所有DROP
命令都支持CASCADE
。当然,其本质的区别随着对象的类型而不同。我们也可以用RESTRICT
代替CASCADE
来获得默认行为,它将阻止删除任何被其他对象依赖的对象。
根据SQL标准,在DROP
命令中指定RESTRICT
或CASCADE
是被要求的。但没有哪个数据库系统真正强制了这个规则,但是不同的系统中两种默认行为都是可能的。
如果一个DROP
命令列出了多个对象,只有在存在指定对象构成的组之外的依赖关系时才需要CASCADE
。例如,如果发出命令DROP TABLE tab1, tab2
且存在从tab2
到tab1
的外键引用,那么就不需要CASCADE
即可成功执行。
对于用户定义的函数,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;
(SQL语言函数的解释见第 37.5 节)。PostgreSQL将会注意到get_color_note
函数依赖于rainbow
类型:删掉该类型会强制删除该函数,因为该函数的参数类型就无法定义了。但是PostgreSQL不会认为get_color_note
依赖于my_colors
表,因此即使该表被删除也不会删除这个函数。虽然这种方法有缺点,但是也有好处。如果该表丢失,这个函数在某种程度上仍然是有效的,但是执行它会导致错误。创建一个同名的新表将允许该函数重新有效。
PostgreSQL为开发者提供了一组丰富的工具来管理对数据的并发访问。在内部,数据一致性通过使用一种多版本模型(多版本并发控制,...
目录pg_rewrite存储对于表和视图的重写规则。表51.43.pg_rewrite Columns列类型描述 oidoid行标识符 rulenamename规则名称 ev_cl...
视图pg_config描述了当前安装的PostgreSQL版本中的编译时配置参数。它存在的本意是用于那些要和PostgreSQL交互的软件包,让它们...
视图pg_timezone_abbrevs提供了对当前被时间输入例程识别的时区缩写的列表。当timezone_abbreviations运行时参数被修改,此视图...
服务器代码内产生的错误、警告和日志消息应该使用ereport或者更老的elog生成。这个函数的使用有些复杂,因此有必要做一些解释。...