Postgresql Postgres 11没有强制执行外键约束

什么会使PostgreSQL违反外键约束？有三个可能的答案，每个答案都与外键由系统触发器在被引用表和引用表上实现这一事实有关.这些触发器没有显示在\dt或information_schema.triggers的输出中，您必须查询目录pg_trigger才能看到它们.

Violate a foreign key by setting session_replication_role

如果为session_replication_role = replica，则正常的触发器不会触发.只有使用以下语句中的ON更改的触发器才会触发:

ALTER TABLE ... ENABLE REPLICA TRIGGER ...
ALTER TABLE ... ENABLE ALWAYS TRIGGER ...

超级用户需要更改session_replication_role，并且需要超级用户修改实现外键的系统触发器.

禁用表上的触发器违反外键约束

这可以通过以下方式完成

ALTER TABLE ... DISABLE TRIGGER ALL

在引用表或引用表上.此语句只能由超级用户执行.根据您是否禁用了被引用表或引用表上的触发器，将不再判断外键约束的某些方面.

使用用户定义的触发器违反级联外键

使用创建约束

ALTER TABLE a ADD FOREIGN KEY (b_id) REFERENCES b (id) ON DELETE CASCADE;

然后创建如下触发器:

CREATE FUNCTION cancel_delete() RETURNS trigger
   LANGUAGE plpgsql AS
$$BEGIN
   RETURN NULL;
END;$$;

CREATE TRIGGER cancel_delete BEFORE DELETE ON a
   FOR EACH ROW EXECUTE FUNCTION cancel_delete();

现在，如果您删除b中的一行，系统触发器将删除a中的行，但您创建的触发器将不会出错地中止这些删除，因为它返回NULL.这将 destruct 引用完整性.

创建损坏的外键的异国方式

• 您可以创建NOT VALID个外键约束(但这将在\d中显示)

• 您可能会遇到数据损坏，其中一个表中的数据会自动丢失

• 您可以直接修改目录，例如，在pg_constraint中插入一行

那么是什么原因导致外键被 destruct 呢？

前两种方法要求超级用户做一些错误的事情，但第三种方法对普通用户开放.如果您可以排除超级用户篡改数据库的可能性，那么它一定是第三种方法.