PL/pgSQL中变量与列名同名会因variable_conflict=error导致“column reference is ambiguous”错误；推荐统一使用p_前缀（参数）和v_前缀（变量）显式区分，而非依赖配置修改。
PL/pgSQL里变量和列名同名导致ERROR: column reference is ambiguous
直接报错，不是警告。只要函数体里出现 seqno = seqno 这种写法，且表里有 seqno 列、函数参数又叫 seqno，PostgreSQL 就会拒绝执行，提示“ambiguous”。这不是语法错误，是运行时解析阶段的语义冲突。
根本原因是 PL/pgSQL 默认启用 variable_conflict = error，它不帮你猜——你得明确告诉它是想用变量还是列。
- 查当前设置：
SHOW plpgsql.variable_conflict; - 临时改当前会话：
SET plpgsql.variable_conflict = use_variable;（只对后续创建的函数生效） - 但这个开关治标不治本：它强制所有同名列引用都指向变量，万一真想更新某列值就翻车了
为什么加前缀比改配置更可靠
加前缀（比如 v_seqno、p_comments1）是主动消除歧义，而不是靠配置“蒙混过关”。它让代码可读、可维护、可静态检查。
-
v_开头表示局部变量（v_seqno），p_开头表示参数（p_comments1），_结尾也可行，关键是统一 - 修改原示例只需两处：
WHERE seqno = p_seqno和comments2 = p_comments1，不再依赖任何配置 - IDE 和 linter 能识别这种命名模式，自动高亮变量使用，降低误读概率
- 团队协作时，别人一眼看出
v_xxx是函数内变量，xxx是表字段，不用翻文档或猜上下文
实际改写示例：从报错到安全
原始出错函数：
CREATE OR REPLACE FUNCTION func1(seqno bigint, comments1 text) RETURNS SETOF testproc LANGUAGE plpgsql AS $$ BEGIN RETURN QUERY UPDATE testproc SET comments2 = comments1 WHERE seqno = seqno RETURNING *; END; $$;
加前缀后（无需改配置）：
CREATE OR REPLACE FUNCTION func1(p_seqno bigint, p_comments1 text)
RETURNS SETOF testproc LANGUAGE plpgsql AS $$
DECLARE
v_row testproc%ROWTYPE;
BEGIN
RETURN QUERY UPDATE testproc
SET comments2 = p_comments1
WHERE seqno = p_seqno
RETURNING *;
END;
$$;
- 参数加
p_前缀，避免和表列冲突 -
DECLARE块里定义的变量也按规则来（如v_row），即使没在 WHERE 中用，也保持风格一致 - 如果函数逻辑变复杂（比如要先查再判断），
v_变量能自然承接中间状态，不会和后续新增的列名撞车
容易被忽略的边界情况
前缀不是万能银弹，这几个点不注意照样踩坑：
- 游标
FOR r IN SELECT ...中的r是记录变量，它的字段名仍可能和参数/列同名，此时仍需用r.seqno显式限定 - 动态 SQL（
EXECUTE）里拼接字符串时，前缀只作用于 PL/pgSQL 变量，不改变 SQL 字符串里的列名解析逻辑 - 如果表本身字段名就带下划线（如
user_id），别硬套p_user_id再叠一层下划线，用p_userid或p_user_id_param更清爽
