9.3 9.4 9.5 9.6 10 11 12 13 14 Current(15)
阿里云PostgreSQL 问题报告 纠错本页面

53.18. pg_depend

目录pg_depend记录数据库对象之间的依赖关系。这些信息允许DROP命令查找必须被DROP CASCADE删除的其他对象,或者在DROP RESTRICT情况下阻止删除。

另请参阅pg_shdepend,它对在一个数据库集簇中共享的对象之间的依赖提供了相似的功能。

表 53.18. pg_depend Columns

列类型

描述

classid oid (references pg_class.oid)

依赖对象所在系统目录的OID

objid oid (references any OID column)

特定依赖对象的OID

objsubid int4

对于一个表列,这里是列号(objidclassid指表本身)。对于所有其他对象类型,此列为0。

refclassid oid (references pg_class.oid)

被引用对象所在的系统目录的OID

refobjid oid (references any OID column)

指定被引用对象的OID

refobjsubid int4

对于一个表列,这里是列号(refobjidrefclassid指表本身)。对于所有其他对象类型,此列为0。

deptype char

定义此依赖关系语义的一个代码,见文本


在所有情况下,pg_depend条目都表示,在不删除依赖对象的情况下,无法删除被引用的对象。 然而,有几种由deptype标识的子类型:

DEPENDENCY_NORMALn

两个独立创建的对象之间的正常关系。依赖对象可以被删除而不影响引用对象。 引用对象只能通过指定CASCADE来删除,这样依赖对象也会被删除。 例如:表列对其数据类型有一个正常依赖关系。

DEPENDENCY_AUTO (a)

依赖对象可以与引用对象分开删除,并且应在引用对象被删除时自动删除(无论是RESTRICT还是CASCADE模式)。 例如:表上的命名约束会自动依赖于表,因此如果表被删除,约束也会消失。

DEPENDENCY_INTERNALi

依赖对象是作为引用对象创建的一部分,并且实际上只是其内部实现的一部分。对依赖对象的直接DROP将被直接禁止(我们会告诉用户对引用对象发出DROP)。对引用对象的DROP将导致自动删除依赖对象,无论是否指定了CASCADE。如果依赖对象必须由于对某个其他对象的依赖关系而被删除,其删除将转换为对引用对象的删除,以便依赖对象的NORMALAUTO依赖行为类似于它们是引用对象的依赖关系。示例:视图的ON SELECT规则在内部上依赖于视图,防止在视图保留的同时删除它。规则的依赖关系(例如它引用的表)就好像它们是视图的依赖关系一样。

DEPENDENCY_PARTITION_PRIP
DEPENDENCY_PARTITION_SECS

依赖对象是作为引用对象创建的一部分,并且实际上只是其内部实现的一部分; 然而,与INTERNAL不同,存在多个这样的引用对象。 除非这些引用对象中至少有一个被删除,否则不得删除依赖对象; 如果有任何一个被删除,无论是否指定了CASCADE,依赖对象都应该被删除。 与INTERNAL不同的是,依赖对象依赖的其他对象的删除不会导致任何分区引用对象的自动删除。 因此,如果删除不通过其他路径级联到至少一个这些对象之一,将被拒绝。 (在大多数情况下,依赖对象与至少一个分区引用对象共享所有非分区依赖关系, 因此,这一限制不会导致阻止任何级联删除。) 主要和次要分区依赖关系的行为相同,只是主要依赖关系更适合用于错误消息; 因此,分区依赖对象应该有一个主要分区依赖关系和一个或多个次要分区依赖关系。 请注意,分区依赖关系是额外添加的,而不是替代对象通常具有的任何依赖关系。 这简化了ATTACH/DETACH PARTITION操作: 只需添加或删除分区依赖关系。 例如:子分区索引对其所在的分区表和父分区索引都有分区依赖关系, 因此,如果其中任何一个被删除,它将消失,否则不会。 对父索引的依赖是主要的,因此如果用户尝试删除子分区索引, 错误消息将建议删除父索引(而不是表)。

DEPENDENCY_EXTENSIONe

依赖对象是扩展(extension)的一个成员,即引用对象(参见 pg_extension)。 依赖对象只能通过引用对象上的 DROP EXTENSION来删除。 在功能上,这种依赖类型与INTERNAL依赖相同,但为了清晰和简化pg_dump而保持分开。

DEPENDENCY_AUTO_EXTENSIONx

依赖对象不是被引用对象的扩展的成员(因此不应被pg_dump忽略), 但它无法在没有扩展的情况下运行,如果扩展被删除,它应该被自动删除。 依赖对象也可以单独删除。 从功能上讲,这种依赖类型与AUTO依赖相同,但为了清晰起见和简化pg_dump,它被保持分开。

未来可能需要其他依赖关系的变种。

要注意的是,两个对象很有可能由不止一个pg_depend条目来链接。例如子分区索引有一个依赖于其关联的分区表的分区类型的依赖关系和依赖于该表索引的每一列的自动依赖关系。此类情形表示多重依赖关系语义的并集,依赖对象的删除可以没有CASCADE,如果其任一依赖关系满足自动删除的条件。相反地,关于哪些对象必须一起删除的所有依赖关系的限制必须满足。

initdb期间创建的大多数对象被视为固定(pinned), 这意味着系统本身依赖于它们。因此,它们永远不允许被删除。 此外,知道固定(pinned)对象不会被删除,依赖机制也不会在pg_depend中 显示对它们的依赖关系。因此,例如,类型为numeric的表列在逻辑上 对numeric数据类型有一个NORMAL依赖关系, 但在pg_depend中实际上并没有这样的条目。