PostgreSQL触发器中不能裸用>>操作符，必须置于SQL上下文（如SELECT INTO或VALUES子句）；>>返回text，->返回jsonb，类型转换需显式声明，字段不存在时均返回NULL。
触发器里直接用 >> 提取 JSONB 字段会报错
PostgreSQL 触发器函数（比如 plpgsql）中不能在 SQL 语句外直接用 >> 运算符——它只在 SQL 表达式上下文中有效，不是 PL/pgSQL 的原生操作符。常见错误是写成：NEW.data >> 'name'，结果触发器编译失败，报 syntax error at or near ">>"。
正确做法是把提取逻辑包在 SQL 查询或赋值语句里，例如用 SELECT ... INTO 或直接在 INSERT/UPDATE 的 VALUES 子句中使用。
- 必须把
>>放在 SQL 执行环境中，不能裸写在 PL/pgSQL 赋值右侧（除非用EXECUTE动态拼接） -
>>返回jsonb类型；若要字符串，得显式转成text，如(NEW.data >> 'name')::text - 字段不存在时
>>返回NULL，不会报错，适合宽松解析
用 BEFORE INSERT OR UPDATE 触发器预处理 JSONB 字段
典型场景：把 payload JSONB 中的 user_id、status 提取出来，存到对应普通列，方便索引和 JOIN。必须用 BEFORE 触发器，才能修改 NEW 记录。
CREATE OR REPLACE FUNCTION extract_jsonb_fields() RETURNS TRIGGER AS $$ BEGIN NEW.user_id := (NEW.payload >> 'user_id')::bigint; NEW.status := (NEW.payload >> 'status')::text; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER t_extract_payload BEFORE INSERT OR UPDATE ON events FOR EACH ROW EXECUTE FUNCTION extract_jsonb_fields();
-
NEW.payload >> 'user_id'返回jsonb，需强制转换类型，否则类型不匹配报错 - 如果
user_id在 JSON 中是字符串（如"123"），用::bigint会失败；此时应先转::text再用CAST(... AS bigint)或NULLIF(..., '')::bigint防空 - 触发器对每行执行一次，高并发写入时注意避免在函数里做复杂 JSON 遍历或子查询
>> 和 -> 的关键区别别搞混
>> 返回 text，-> 返回 jsonb —— 这直接影响你在触发器里怎么用。比如想把嵌套对象整个存进另一列，该用 ->；想取字符串做条件判断，优先用 >>。
NEW.data >> 'meta' → text（如 '{"k":1}' 的字符串字面量）NEW.data -> 'meta' → jsonb（可继续链式调用 <code>->或>>）NEW.data -> 'meta' >> 'k' → text（等价于 <code>(NEW.data -> 'meta') >> 'k'）- 误用
>>提取对象再试图>> 'k'会得到 NULL，因为上一步已转成字符串，不再支持 JSON 操作
NULL 安全和性能要注意的几个点
JSONB 字段为空、字段名拼错、值为 null（JSON null）时，>> 全部返回 SQL NULL。这看起来友好，但容易掩盖数据质量问题。
- 用
COALESCE((NEW.data >> 'id')::text, 'unknown')做兜底，但注意COALESCE不阻止类型转换失败 - 频繁提取同一路径建议建生成列（PostgreSQL 12+）：
ALTER TABLE t ADD COLUMN id_text TEXT GENERATED ALWAYS AS (data >> 'id') STORED;，比触发器更轻量 - 如果 JSONB 很大（MB 级），每次触发器都解析整个字段有开销；考虑只在必要字段变更时才提取，可用
pg_trigger_depth() = 0 AND TG_OP = 'INSERT'加简单守卫
最易被忽略的是类型转换的静默失败——比如把 "true" 的 JSON 字符串直接 ::boolean 会成功，但把 true（JSON bool）用 >> 提取后变成 'true' 字符串，再 ::boolean 就报错。这时候该用 -> 保持类型，或统一走 jsonb_typeof() 判断后再分支处理。
