91477695a56755d36a.png (40.7 KB, 下载次数: 71)
2026-1-4 20:00 上传
列约束与表约束
pg_constraint 文档中明确指出：
列约束不会被特殊处理，每个列约束在内部都等价于某种表约束。
SQL 层面上，约束可以写在列定义后，也可以写成表约束，例如：
CREATE TABLE products_oct (
price numeric CHECK (price > 0)
);
CREATE TABLE products_nov (
price numeric,
CHECK (price > 0)
);
第一种写法只作用于单列，第二种写法可以作用于多列。但在 PostgreSQL 内部，这两种方式最终都会被统一记录为 pg_constraint 中的一行数据。
因此，无论约束以哪种形式定义，都可以通过 ALTER TABLE .. DROP CONSTRAINT .. 删除。系统目录中并不存在“列约束”的特殊标识，它只是作用于单列的表约束。
下面的查询用于查看两个示例表中的约束定义：
SELECT
rel.relname AS table_name,
c.conname,
c.contype,
c.conrelid::regclass AS table_ref,
c.conkey,
pg_get_constraintdef(c.oid, true) AS constraint_def
FROM pg_constraint c
JOIN pg_class rel ON rel.oid = c.conrelid
WHERE rel.relname IN ('products_oct', 'products_nov');
⚡ 查询要点说明
pg_class 用于存储所有关系对象的元数据。
relname 为表的名称，由于 pg_constraint 中仅保存表的 OID，需要通过 rel.oid = c.conrelid 进行关联。
conrelid 表示约束所属表的 OID。
conname 为约束名称，约束名称在单表内唯一，可由系统自动生成，也可在 DDL 中显式指定。
contype 表示约束类型（c、f、n、p、u、x、t）。
conkey 为属性编号数组，用于标识约束涉及的列（如 {1} 表示第一列，{1,3} 表示第一和第三列）。
pg_get_constraintdef() 为系统函数，用于获取约束定义文本。
查询结果如下所示。两种约束在内部表示上几乎完全一致，仅约束名称和所属表不同。
-[ RECORD 1 ]--+---------------------------
table_name | products_nov
conname | products_nov_price_check
contype | c
table_ref | products_nov
conkey | {1}
constraint_def | CHECK (price > 0::numeric)
-[ RECORD 2 ]--+---------------------------
table_name | products_oct
conname | products_oct_price_check
contype | c
table_ref | products_oct
conkey | {1}
constraint_def | CHECK (price > 0::numeric)
约束触发器（Constraint Trigger）
在 pg_constraint 中，使用 CREATE CONSTRAINT TRIGGER 创建的约束触发器同样会生成记录，其 contype 标记为 t。常见约束如 UNIQUE 为 u，CHECK 为 c。
约束触发器是一种将触发器机制与约束系统结合的特殊形式，主要用于数据一致性校验。
可延迟触发器（Deferrable Triggers）
约束触发器通过 CREATE CONSTRAINT TRIGGER 创建，语法与普通触发器类似，但指定 CONSTRAINT 后生成的是约束触发器。其核心区别在于，约束触发器可以通过 SET CONSTRAINTS 控制触发执行时机。
其执行时机可通过 SET CONSTRAINTS 控制：
IMMEDIATE：语句结束时检查
DEFERRED：事务提交时检查
与普通触发器不同，约束触发器允许在事务级别延迟执行，并在运行时动态调整。
⚠️ WHEN 条件始终立即评估
即使触发器本身是延迟执行的，WHEN 子句仍在语句执行时立即判断，用于决定是否进入执行队列。
AFTER 触发器
在创建触发器时，需要指定触发函数的执行时机：BEFORE、AFTER 或 INSTEAD OF。约束触发器只能定义为 AFTER 触发器。
约束触发器并不用于改变数据处理流程，而是在数据操作完成后进行条件校验。约束的核心目标是数据验证，而普通触发器通常用于数据修改。约束触发器属于校验机制的一部分，当其所实现的约束条件被违反时，应当抛出异常。
FOR EACH ROW 触发器
创建触发器时，还需要指定触发粒度：
FOR EACH ROW：对受影响的每一行执行一次
FOR EACH STATEMENT：每条 SQL 语句只执行一次
约束触发器只能定义为 FOR EACH ROW，这是因为约束校验依赖于单行数据的具体取值。
需要注意的是，约束触发器不支持 OR REPLACE 选项，因此只能通过删除后重新创建的方式进行修改。
为什么需要约束触发器
在《Triggers to enforce constraints in PostgreSQL》一文中，Laurenz Albe 指出，某些需要在表级别强制执行的规则，无法通过常规约束直接表达，此时可借助触发器机制实现。文中结合示例说明了适用场景，并分析了约束与触发器在 MVCC 行为上的差异。
在实际系统中，约束触发器很少由用户显式创建。PostgreSQL 更多将其作为约束实现的内部基础机制使用，尤其是在外键约束中。外键依赖系统自动生成的约束触发器实现，这一设计也使外键能够支持 DEFERRABLE 和 INITIALLY DEFERRED 等特性。
什么是域
域可以理解为“带约束的数据类型”。它基于已有类型（如 text、integer），但可以附加 NOT NULL、CHECK 约束或默认值，用于集中定义数据规则。
示例如下：
CREATE DOMAIN email_address AS text
CHECK (VALUE ~* '^[^@]+@[^@]+\.[^@]+$');
CREATE TABLE users (
id serial PRIMARY KEY,
email email_address NOT NULL
);
-- This will fail
INSERT INTO users(email) VALUES ('not-an-email');
-- This will be successful
INSERT INTO users(email) VALUES ('ok@example.com');
上述示例中定义了一个名为 email_address 的新类型。所有使用该类型的列，在插入或更新数据时都会自动校验正则表达式。即使表本身未显式定义 CHECK 约束，非法值仍会被拒绝。
通常情况下，约束是附加在表上的，但 PostgreSQL 同样支持在域上定义约束。以下查询演示了如何从 pg_constraint 中查询定义在域上的约束：
SELECT c.conname,
pg_get_constraintdef(c.oid, true) AS definition,
t.typname AS domain_name
FROM pg_constraint c
JOIN pg_type t ON t.oid = c.contypid
WHERE c.contype = 'c'
AND c.contypid <> 0;
⚡ 查询要点说明
pg_constraint 存储所有类型的约束，包括表约束和域约束
pg_type 存储数据类型信息，包括域
contypid 表示约束所属域的 OID。当 contypid 非 0 时，约束附加在域上；当为 0 时，约束附加在表上，此时使用 conrelid
通过 JOIN pg_type t ON t.oid = c.contypid 获取域名称
域仅支持 CHECK 约束，因此筛选条件为 c.contype = 'c'
pg_get_constraintdef() 用于获取约束定义文本，与 CREATE DOMAIN 中的定义一致
查询结果如下，展示了约束名称、定义内容以及所属域：
conname | definition | domain_name
-------------------+---------------------------------------+-------------
email_address_check|CHECK (VALUE ~* '^[^@]+@[^@]+\.[^@]+$')| email_address
总结
通过 pg_constraint 系统目录，可以系统理解 PostgreSQL 中各类约束的内部表示方式。无论是列约束、表约束、约束触发器，还是域上的约束，本质上都通过同一套机制进行管理，这是 PostgreSQL 约束体系设计上的关键特点。
| 欢迎光临 重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛 (http://bbs.cqsztech.com/) | Powered by Discuz! X3.2 |