平时写PostgreSQL的存储过程，你是不是总遇到这些糟心事：变量明明定义了却死活不生效，引号写得眼花缭乱数不清，抛错了只知道喊“出错了”却没半点有用信息，或者逻辑看着没问题但执行起来慢得离谱？
作为天天和PL/pgSQL打交道的开发者，我踩过不少坑，也摸透了它的“脾气”。今天就从实战角度，把PL/pgSQL的事务管理、错误处理、底层实现和开发小技巧掰开揉碎了说。
一、错误处理：别只会抛错，要抛得“有水平”
写PL/pgSQL最基础的就是处理错误，但很多人只会用RAISE EXCEPTION '出错了'，既没说清错在哪，也没给半点调试线索，排查起来能把人逼疯。其实PL/pgSQL的错误处理远比这灵活。
1. RAISE语句：不止会“喊错”，还会“说清错”
RAISE不是只有EXCEPTION这一种姿势，它有6个级别：DEBUG（调试用）、LOG（写日志）、INFO（普通信息）、NOTICE（通知）、WARNING（警告）、EXCEPTION（异常）。只有EXCEPTION会终止当前事务，其他级别只是打日志或给客户端提示，具体哪些能看到、哪些写日志，靠log_min_messages和client_min_messages这两个参数控制。
日常用得最多的是带格式字符串的写法，比如用户传了个不存在的ID：
RAISE NOTICE '正在调用创建任务函数，任务ID：%', v_job_id; -- 调试时看执行状态
RAISE EXCEPTION '不存在的用户ID --> %', user_id USING HINT = '请检查你的用户ID是否正确'; -- 抛错+给提示
这里的%就是占位符，会被后面的变量值替换，比拼接字符串清爽多了。如果要抛特定类型的错（比如主键重复），还能指定SQLSTATE编码或错误条件名：
-- 两种写法等效，都是抛“唯一约束冲突”错
RAISE '重复的用户ID：%', user_id USING ERRCODE = '23505';
RAISE unique_violation USING MESSAGE = '重复的用户ID：' || user_id;
要是在EXCEPTION捕获块里想把错误重新抛出去，直接写RAISE;就行，不用再写一遍错误信息。
2. ASSERT断言：调试专用，别拿来处理业务错
开发阶段可以用ASSERT做“自检”，比如断言参数非空、计算结果符合预期：
ASSERT user_id IS NOT NULL, '用户ID不能为空';
如果条件不满足，会抛ASSERT_FAILURE异常。不过要注意，这东西只适合调试，生产环境可以把plpgsql.check_asserts设为off关掉，别用它处理“用户输错参数”这种常规错误——这类场景还是用RAISE更合适。
二、事务管理：PL/pgSQL里的“隐形规则”
很多人刚写PL/pgSQL会犯一个错：在函数里写BEGIN; COMMIT;，结果报错。其实PL/pgSQL函数本身不能显式控制事务，它的所有操作都跑在调用者的事务里——函数里的逻辑要么全成功，要么全失败。
真正有用的是EXCEPTION子句，它能帮你“挽救”错误，或者至少把错误信息记下来。比如写个转账函数，扣钱和加钱必须都成功：
CREATE OR REPLACE FUNCTION transfer_money(from_id int, to_id int, amount numeric)
RETURNS void AS $PROC$
BEGIN
-- 扣钱
UPDATE account SET balance = balance - amount WHERE id = from_id;
-- 加钱
UPDATE account SET balance = balance + amount WHERE id = to_id;
-- 检查是否真的更新了（比如账号不存在）
IF NOT FOUND THEN
RAISE EXCEPTION '转账失败：账号不存在';
END IF;
EXCEPTION
WHEN OTHERS THEN
-- 捕获所有错误，记录日志
RAISE LOG '转账出错：%', SQLERRM;
-- 重新抛出错误，让调用者知道失败了
RAISE;
END;
$PROC$ LANGUAGE plpgsql;
这里的EXCEPTION WHEN OTHERS会捕获所有错误，先记日志，再用RAISE;重新抛错——既保留了错误信息，又能让调用者感知到失败，比直接吞掉错误强多了。
三、底层实现：知道这些，少走一半弯路
很多时候我们写的代码“看着对，跑着错”，其实是没搞懂PL/pgSQL的底层逻辑，主要是两个点：变量替换和计划缓存。
1. 变量替换：别指望变量能替表名/列名
PL/pgSQL处理变量不是简单的“字符串替换”，而是把变量转成查询参数，而且只在语法允许的地方替换。比如这句：
INSERT INTO foo (foo) VALUES (foo(foo));
前三个foo分别是表名、列名、函数名，只有最后一个才可能是变量——哪怕你定义了foo变量，前三个也不会被替换。
如果变量名和列名重了（比如函数里有个foo变量，表也有foo列），PL/pgSQL会直接报错。解决办法超简单：
- 给变量加前缀，比如
v_foo，列名不用前缀，从根源避免冲突； - 用块标签限定变量，比如
<<func>>块里的func.foo； - 实在改不了，就设
#variable_conflict use_variable，让PL/pgSQL优先认变量。
2. 计划缓存：为什么函数越跑越慢？
PL/pgSQL第一次执行时，会把函数解析成指令树，里面的SQL语句第一次跑的时候会生成“预处理语句”和执行计划，缓存起来复用——这本来是为了快，但有时候会帮倒忙。
比如一个查询条件依赖变量，第一次执行时变量值是1，生成的计划适合查小数据；后来变量值变成10000，缓存的计划就不是最优的了。这时候别死磕缓存，用EXECUTE动态拼接SQL（虽然每次要重新解析，但能拿到最优计划）：
-- 别这么写：缓存的计划可能不适用所有id
SELECT * FROM big_table WHERE id = v_id INTO result;
-- 动态SQL：每次生成新计划，适合变量值差异大的场景
EXECUTE 'SELECT * FROM big_table WHERE id = $1' INTO result USING v_id;
另外要注意，触发器函数给不同表用、多态参数的函数，PL/pgSQL会单独缓存计划，不用怕类型不兼容的问题。
四、开发技巧：这些小细节，能省你半天时间
最后聊几个能提升开发效率的小技巧，全是实战中总结的：
1. 引号处理：别数引号了，用美元符！
写函数体时，最烦的就是单引号转义——比如要拼接带单引号的SQL，得写6个、10个引号，数都数错。换成美元符$xxx$包裹函数体，里面的单引号不用转义：
-- 噩梦写法：数不清的引号
CREATE FUNCTION bad_quote() RETURNS text AS '
DECLARE
str text;
BEGIN
str := '' AND name LIKE ''''foobar'''''';
RETURN str;
END;
' LANGUAGE plpgsql;
-- 清爽写法：美元符包裹
CREATE FUNCTION good_quote() RETURNS text AS $PROC$
DECLARE
str text;
BEGIN
str := {mathJaxContainer[0]};
RETURN str;
END;
$PROC$ LANGUAGE plpgsql;
哪怕嵌套拼接，只要换不同的美元符分隔符（比如$Q$），就不会冲突，谁用谁知道香。
2. 函数重载：用CREATE OR REPLACE，测试超方便
写函数时别用CREATE FUNCTION，改用CREATE OR REPLACE FUNCTION——改完代码后，在psql里用\i 函数文件.sql就能直接重载，不用删了重建，测试起来贼快。
3. 提前开“警告检查”，把错误掐死在开发阶段
开发环境里，把plpgsql.extra_warnings设为all，能提前发现很多低级错误：
shadowed_variables：变量遮蔽（比如参数名和变量名一样）；strict_multi_assignment：多变量赋值时数量不匹配；too_many_rows：查询返回多行但用INTO接收（只会取第一行，大概率是逻辑错）。
这些警告能帮你在测试阶段就发现问题，比上线后报错强一百倍。
最后：核心要点记牢，少踩坑
- 错误处理：
RAISE按场景选级别，加USING补详情/提示；ASSERT只用于调试，别碰业务逻辑； - 事务：函数无显式事务，靠
EXCEPTION捕获错误，RAISE;重新抛错； - 底层：变量不能替表名/列名，计划缓存可能影响性能，动态逻辑用
EXECUTE； - 技巧：美元符省引号，
CREATE OR REPLACE方便调试，开发开额外警告检查。
PL/pgSQL其实不难，难的是摸透它的“脾气”。避开这些坑，用好这些技巧，写存储过程会轻松很多——毕竟我们的目标是写能跑、好调、不出错的代码，而不是和语法死磕。
