很多做应用开发的同事一提到 PostgreSQL 里的“赋值”，第一反应就是UPDATE user SET name = '张三'。这个理解没错，但只停留在“改字段”的层面。真正进入 PostgreSQL 的开发（尤其是写存储过程、函数、触发器、批量数据处理脚本）之后，“赋值”的含义会瞬间变宽：变量绑定、行类型接收、结果集落表、数组展开、动态 SQL 传参……每一个场景的语法和坑都不一样。
这篇文章我想从实际开发的角度，把 pg 数据库开发中你一定会遇到的赋值场景拆开聊一遍。不会去背文档，而是按“我接到一个活儿，要处理什么数据，代码该怎么写，写完遇到过什么鬼问题”的思路来写。内容适合两类人：一类是刚接触 PL/pgSQL 的开发者，需要系统搞明白各种赋值写法；另一类是写过一阵子但老在某些细节上翻车的人，可以对照着避坑清单自查。说白了，赋值这件事，在 pg 里真不是=号那么简单。
1. 先分清两种“赋值”：SQL 到字段的复制，和代码里的变量绑定
1.1 SQL 赋值：面向数据行的写入逻辑
在 PostgreSQL 中，最常见的赋值行为发生在 DML 语句里。INSERT、UPDATE本质上都是把某个值写入某一个字段，这个动作可以被理解为“SQL 层面的赋值”。它有一个特点：以集合为单位，一次性作用到多行数据上。比如说：
UPDATE 模拟订单表 SET 订单状态 = '已关闭' WHERE 支付超时标识 = 1;这里订单状态 = '已关闭'就是一种赋值，但它不是逐行循环做，而是整个表里满足条件的行一次性全部生效。这正是 SQL 赋值最核心的思维：不需要关心循环，只描述“目标状态”。
很多刚入门的开发者会把应用代码里的赋值习惯带过来，喜欢写“逐条更新”的逻辑，也就是一次取一条记录，改一个字段，再取下一条……这种写法在数据量小的时候没问题，但一旦数据量上到几万、几十万行，性能就会直线崩溃。因为每一条语句都意味着事务、锁、解析、执行计划的反复开销。
所以我认为，在 pg 开发里凡是能用一条 UPDATE 或 INSERT 完成的赋值，都应该优先考虑集合写法。这不是什么高深理论，纯粹是实际性能和代码可维护性的选择。
1.2 变量赋值：PL/pgSQL 里的内存操作
第二种赋值发生在 PL/pgSQL 语言内部。不论是写函数、存储过程还是 DO 匿名块，都会需要临时变量来缓存中间计算结果。这种赋值在作用域、生命周期上与 SQL 赋值完全不同：它只在当前会话或当前函数内有效，函数执行完毕变量就被释放，不影响数据库里的真实数据。
DO $$ DECLARE 当前时间截点 TIMESTAMP; 影响行数 INTEGER := 0; BEGIN 当前时间截点 := clock_timestamp(); UPDATE 模拟订单表 SET 最后催付时间 = 当前时间截点 WHERE 应付金额 > 0; GET DIAGNOSTICS 影响行数 = ROW_COUNT; RAISE NOTICE '本次更新行数: %', 影响行数; END $$;上面这段代码里出现了三种赋值形式：
- 在 DECLARE 里用
:= 0给变量赋初始值； - 在 BEGIN 块里用
:= clock_timestamp()给时间变量赋值； - 用
GET DIAGNOSTICS把系统状态（ROW_COUNT）赋值给普通变量。
这就需要开发者特别注意：PL/pgSQL 已声明的变量，必须用:=或=赋值，不能直接用 SELECT 塞进去。如果想把查询结果赋给变量，要么用SELECT INTO，要么用INTO子句。
2. 开发中最高频的几类赋值场景拆解
2.1 查询结果赋值：SELECT INTO、普通 SELECT 与分号陷阱
把 SQL 查询结果赋给变量，在存储过程开发中是“吃饭一样平常”的操作。但用法上有几个版本差异，且很容易踩分号的坑。
PostgreSQL 支持两种写法：
写法一：
SELECT 实际金额 INTO 目标变量 FROM 模拟订单表 WHERE 订单编号 = 'ABC123';写法二：
SELECT 实际金额 INTO 目标变量 FROM 模拟订单表 WHERE 订单编号 = 'ABC123';这里要强调一个老手都容易犯的错：在plpgsql函数里，这只语句的结尾必须使用;结尾，因为整个 PL/pgSQL 的语法要求语句结束符；但在SQL 语法层面（比如直接用 psql 执行）SELECT INTO会创建一个新表，用途完全不一样。
什么场景用什么，真的要用点心。举个例子，在函数里写：
SELECT 订单号, 订单金额 INTO 最新订单号, 最新订单金额 FROM 模拟订单表 ORDER BY 下单时间 DESC LIMIT 1;这种写法把“查询”和“赋值”合二为一，如果查询返回零行，那变量会被置为 NULL；如果返回多行，plpgsql 不会报错，只会取第一行赋值。这一点和很多人直觉不一样，也很容易导致 bug：你本意是查出唯一记录，结果因为数据问题出现了多行，而代码并不报错，数据就悄然错了。
想强制约束唯一性，正确的做法是查询时就用LIMIT 1，或者用聚合函数保证返回一行。这是经验之谈，真心建议写进去。
2.2 数组与 JSON 的展开赋值：一行变多行
有一种“赋值”并不是简单地把值塞进去，而是把一个复合结构打散成多行再落表。常见于从接口拿回来一段 JSON，或者数据库里存的是数组字段，需要拆开关联子表。
比如一个订单表里存了商品 JSON，现在需要把所有商品明细展开成一张明细表：
INSERT INTO 模拟订单明细表 (订单编号, 商品名称, 商品数量) SELECT 订单编号, 明细记录 ->> '名称', 明细记录 ->> '数量' FROM 模拟订单表, jsonb_array_elements(模拟订单表.商品明细JSON) AS 明细记录 WHERE 下单时间 >= '2024-01-01';jsonb_array_elements这个函数会把 JSON 数组展开成一组记录，配合SELECT赋值到新的明细表里。这种操作的底层逻辑是横向铺开，它和普通赋值不同：赋值目标不是单个变量，而是一张表的若干行。
如果在存储过程里处理这类逻辑，也可以把展开后的结果赋给一个临时表，或者直接使用FOREACH循环逐条处理：
DECLARE 商品项 JSONB; BEGIN FOREACH 商品项 IN ARRAY jsonb_path_query_array(订单记录, '$.商品列表[*]') LOOP RAISE NOTICE '商品: %', 商品项 ->> '名称'; END LOOP; END;这种“数组遍历 + 逐项操作”的组合,在实际的订单拆分、标签提取、日志解析场景里出现频率极高。建议熟练掌握jsonb_each与jsonb_array_elements的区别：前者返回key-value对，后者直接返回数组元素，二者用于不同类型的 JSON 结构。
2.3 行类型与复合类型赋值：不止标量，还有整行
除了INTEGER、TEXT、TIMESTAMP这些标量变量，PostgreSQL 还支持直接把一行数据作为一个复合类型赋值给变量。这个特性写数据处理脚本时特别省事，不用一个个字段去取。定义起来也很直观：
DECLARE 订单记录 RECORD; BEGIN SELECT * INTO 订单记录 FROM 模拟订单表 WHERE 订单编号 = 'ORD-2024001'; RAISE NOTICE '订单号: %, 客户: %, 金额: %', 订单记录.订单编号, 订单记录.客户姓名, 订单记录.总金额; END;这里使用RECORD类型声明变量，SELECT * INTO会把一整行赋值进去。之后访问字段时使用变量名.字段名的方式即可。
在 PostgreSQL 中还有更“原生”的行类型用法：如果已知表结构，可以直接用表名作为变量类型声明，这样在编译期就有字段提示，比如：
DECLARE 订单记录 模拟订单表%ROWTYPE; BEGIN SELECT * INTO 订单记录 FROM 模拟订单表 WHERE 订单编号 = 'ORD-2024001'; END;用%ROWTYPE的好处是结构自动跟表同步，以后表增加字段，函数里不需要改动声明部分，维护成本更低。我在实际项目中，凡是涉及单行完整数据的处理，一律用%ROWTYPE，很少手动列出字段，这也养成了对表结构变更比较淡定的习惯。
2.4 动态 SQL 赋值：EXECUTE INTO 与 USING 传参
动态 SQL 是指把一段字符串拼接成 SQL 再执行，常用于处理表名、条件都动态变化的场景。比如做一个通用的数据归档任务，按月把所有表的过期数据移到历史表。这种场景里就没法写静态的SELECT INTO了，必须用EXECUTE ... INTO。
EXECUTE 'SELECT count(*) FROM ' || 表名 || ' WHERE 创建时间 < $1' INTO 过期数量 USING 现在时间 - INTERVAL '6 month';这段代码有几个关键点：
EXECUTE后面跟的是一段文本，文本内部不能直接写变量，参数一律用$1占位；- 之后用
INTO承接返回结果，赋给变量； - 占位参数用
USING传进去，避免拼接字符串带来的 SQL 注入风险。
一个常见的需求是：执行某个 UPDATE 之后，想知道影响行数。可以使用GET DIAGNOSTICS 变量 = ROW_COUNT;完成赋值，这在动态 SQL 里同样适用：
EXECUTE 'UPDATE 模拟订单表 SET 处理状态 = 1 WHERE 订单状态 = 待处理'; GET DIAGNOSTICS 更新行数 = ROW_COUNT;动态 SQL 是一种非常强大但也很容易混乱的技术，建议严格控制拼接内容，凡是用户可控的输入都不要直接拼进 SQL 文本，哪怕是表名字段名，也最好通过白名单校验后再拼接。
2.5 带返回值的函数赋值：默认值、OUT 参数与 RETURNING
PostgreSQL 函数可以定义得比较灵活。除了常规的 RETURNS 返回值，还可以定义OUT参数，此时函数调用结果可以直接赋给多个变量，省去二次解析。例如：
CREATE OR REPLACE FUNCTION 计算订单统计数据( IN 开始时间 TIMESTAMP, IN 结束时间 TIMESTAMP, OUT 订单总数 INTEGER, OUT 成交总额 NUMERIC ) LANGUAGE plpgsql AS $$ BEGIN SELECT count(*), coalesce(sum(实际支付金额), 0) INTO 订单总数, 成交总额 FROM 模拟订单表 WHERE 下单时间 BETWEEN 开始时间 AND 结束时间; END $$;调用时就可以直接把结果赋给两个变量：
SELECT 计算订单统计数据('2024-01-01', '2024-01-31') INTO 订单量, 总额度;或者直接：
SELECT * FROM 计算订单统计数据('2024-01-01', '2024-01-31');如果你写的函数只有一个返回值，那两种赋值写法都可以：
金额 := 计算订单总额('2024-01-01');SELECT 计算订单总额('2024-01-01') INTO 金额;在 INSERT / UPDATE 语句里，还有一个极其常用的RETURNING赋值手法。比如插入一条订单后，需要立刻拿到自动生成的 ID，不需要再查一遍：
INSERT INTO 模拟订单表 (客户编号, 商品编号, 下单时间) VALUES ('C001', 'P100', now()) RETURNING 订单编号 INTO 新订单号;这类写法在写 API 接口的数据访问层时特别实用，能省掉一次多余的查询。很多 ORM 在底层其实也是这么实现的。
3. 零散知识点并不够，我来走一个完整的仿真开发流程
只讲碎片语法没有说服力，我模拟一个“订单批处理”的开发场景，把之前提到的大部分赋值手法串起来。这一节你可以直接当作代码模板来抄，所有表名、字段名都是虚构的，实际使用替换成自己的即可。
3.1 场景定义：给超时未支付的订单做状态流转
假设业务规则是：下单超过 30 分钟且未支付的订单，自动流转为“已取消”，并释放对应商品的预占库存。这个逻辑一般是定时任务调用的，底层会写进一个存储过程里。
表结构简化如下（实际项目请自行设计）：
CREATE TABLE 模拟订单表 ( 订单编号 BIGSERIAL PRIMARY KEY, 客户编号 BIGINT NOT NULL, 商品编号 BIGINT NOT NULL, 下单时间 TIMESTAMP NOT NULL DEFAULT clock_timestamp(), 订单状态 VARCHAR(20) NOT NULL DEFAULT '待支付', 预占库存号 VARCHAR(40) ); CREATE TABLE 模拟库存表 ( 商品编号 BIGINT PRIMARY KEY, 可售数量 INTEGER NOT NULL, 锁定数量 INTEGER NOT NULL DEFAULT 0 );3.2 编写批处理函数
CREATE OR REPLACE FUNCTION 批量取消超时订单() RETURNS INTEGER LANGUAGE plpgsql AS $$ DECLARE 超时订单数量 INTEGER := 0; 当前处理时间 TIMESTAMP := clock_timestamp(); 失效订单记录 RECORD; BEGIN FOR 失效订单记录 IN SELECT 订单编号, 商品编号, 预占库存号 FROM 模拟订单表 WHERE 订单状态 = '待支付' AND 下单时间 < 当前处理时间 - INTERVAL '30 minutes' LIMIT 1000 LOOP UPDATE 模拟订单表 SET 订单状态 = '已取消', 最后更新时间 = 当前处理时间 WHERE 订单编号 = 失效订单记录.订单编号; IF FOUND THEN UPDATE 模拟库存表 SET 锁定数量 = 锁定数量 - 1 WHERE 商品编号 = 失效订单记录.商品编号; 超时订单数量 := 超时订单数量 + 1; END IF; END LOOP; RETURN 超时订单数量; END $$;在这个函数里，赋值手法全部被串起来了：
DECLARE里的初始化赋值：超时订单数量 INTEGER := 0clock_timestamp()赋值给时间变量FOR ... IN SELECT把查询结果逐行赋给RECORD类型变量- 循环体内
超时订单数量 := 超时订单数量 + 1的累加赋值 RETURN把结果返回给外层调用
3.3 调用函数并观察效果
SELECT 批量取消超时订单();执行会直接返回取消的单量。也可以放进事务里做安全校验：
BEGIN; SELECT 批量取消超时订单(); ROLLBACK;这样会验证逻辑是否正确，但不会真正改动业务数据。实际执行时可以先小范围跑一批，再用 SELECT 抽样检查状态，确认无误后再全量执行。很多生产事故都是因为直接跑全量导致锁表或误更新，建议养成先LIMIT 100试跑的习惯。
这个例子虽然简单，但已经覆盖了标量赋值、行赋值、INTO 赋值、累加赋值、返回值赋值五大类常见用法，足以体现 PL/pgSQL 开发中赋值的核心价值。接下来，重点聊聊我踩过的坑。
4. 赋值开发中的经典翻车现场与排查手册
4.1 字段名和变量名重名，翻车率极高
PL/pgSQL 有一个规矩：函数内部变量与表字段如果同名，优先引用变量。这就导致一个经典的 bug：
CREATE OR REPLACE FUNCTION 错误示范(订单状态 TEXT) RETURNS INTEGER AS $$ DECLARE 订单状态 TEXT; BEGIN SELECT count(*) INTO 当前数量 FROM 模拟订单表 WHERE 订单状态 = '待支付'; END $$;当函数参数或内部变量名恰好是订单状态，而查询条件里也用订单状态 = '待支付'，PG 会把左边的订单状态解析成变量而不是数据表的列，于是查询条件永远成立，或输出完全错误的结果。这个问题在代码 review 时肉眼很难发现，只有通过日志和测试数据对比才能暴露。
解决方式有两种：
- 变量名统一加前缀，比如
v_订单状态； - 查询条件中显式写明表名：
WHERE 模拟订单表.订单状态 = '待支付'。
我个人的习惯是两者结合，变量加前缀，SQL 中所有字段都带表别名，这样既不混淆，也好维护。
4.2 NULL 赋值的隐性传染
另一个大坑是：把一个 NULL 值赋值给变量，再拿变量去参与运算，结果经常不符合直觉。因为 SQL 的 NULL 参与算术运算会全部变成 NULL。
DECLARE 已付金额 NUMERIC := NULL; 应收金额 NUMERIC := 100; 差额 NUMERIC; BEGIN 差额 := 应收金额 - 已付金额; END;结果差额是 NULL，而不是 100。很多报表开发都在这上面吃过亏。我的建议是：凡是可能为 NULL 的金额字段，统一用COALESCE兜底转成 0 再代入运算。比如：
差额 := 应收金额 - COALESCE(已付金额, 0);4.3 SELECT INTO 与普通 SELECT 的语义混淆
再次强调一下开发中经常遇到的误区。在 PL/pgSQL 中：
SELECT count(*) INTO 变量 FROM 表名;这是把 count 结果赋给变量，合法且常用。但如果你用纯 SQL 模式执行：
SELECT count(*) INTO 新表 FROM 原表;在 SQL 层它是创建一张新表，把结果写入新表。这个语义完全不一样。
如果不小心在 psql 里把SELECT INTO当成赋值来用，很可能会意外创建一张表，而且因为名称冲突导致后续报错。排查此类问题的时候，先确认你是在函数体内还是函数体外，再确认当前语言上下文（plpgsql vs SQL）。
4.4 FOUND 状态与 GET DIAGNOSTICS
在写条件逻辑时，经常需要判断“上一条赋值/操作是否真的找到数据”。可以用IF FOUND THEN来判断，也可以用GET DIAGNOSTICS 变量 = ROW_COUNT;拿到具体行数。
这里有一个特性：FOUND在SELECT INTO有返回行时为真，无返回行为假；而ROW_COUNT则是查询返回的实际行数。如果查询返回 0 行，ROW_COUNT也是 0。
建议在需要精确判断影响行数时使用GET DIAGNOSTICS，而只关心“有没有”时使用FOUND。两者组合使用可以处理更复杂的多表联动逻辑。
4.5 事务内的赋值回滚行为
每次可能会有点绕：你在 plpgsql 函数内部对变量做赋值，不会因为后续事务回滚而“回滚”变量本身。变量是内存上的值，事务只影响数据库数据。这意味着如果你在函数中先给变量赋值超时订单数量 := 5，之后一个 SQL 操作遇到异常抛错回滚，但这个变量依然保持 5。如果你在异常块里重新赋值或做其他逻辑，需要自己掌握好状态。
所以，一个稳妥的处理习惯是：不要依赖“未发生异常”来给变量赋默认值，最好在进入事务时显式初始化所有关键变量，或者使用默认值声明。
5. 实操总结和经验沉淀：怎么把“赋值”写出水平
从上面的拆解能感觉到，PostgreSQL 开发中的赋值，远不是填个等号那么简单。它包含了 SQL 层面的集合更新、程序层面的变量绑定、动态 SQL 的占位传参、以及复合类型的行记录操作。掌握这些规则，才能在写存储过程、批处理脚本时游刃有余。
我一般建议用这样的顺序来组织赋值相关代码：
- 能一条 SQL 做完整赋值（集合更新）的，不写循环；
- 必须循环时，用
FOREACH或FOR ... SELECT的批量取数方式； - 所有查询结果赋值到变量时，先想清楚返回行数：零行会 NULL，多行只取第一行；
- 所有字段名和变量名刻意区分，避免同名冲突；
- 涉及金额、数量的变量运算，统一
COALESCE防 NULL； - 动态 SQL 一律用
USING传参，严禁字符串拼接用户输入。
踩了这么多坑之后，我最大的体会是：PostgreSQL 的赋值规则只要系统过一遍，并不难。难的是在真实数据、各种边界条件和多表关联下还能写出稳定、不出错、可维护的赋值逻辑。这也是为什么我建议开发者多在复杂 query 和函数调试上下功夫，而不是只盯着 INSERT/UPDATE 这种表面功夫。如果你手头正好在写 pg 的存储过程，建议先用一个测试表把本文里所有类型跑一遍，再往业务上迁移，可以避开绝大多数隐性 bug。
