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

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

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

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

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

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