臭鼠标从一次线上事故说起：类型不匹配在存储过程里的放大效应
先讲个我真实经历的事。去年给一个订单系统做性能优化，有个PL/pgSQL写的报表存储过程，每天凌晨跑批。某天突然报错：function numeric_eq(integer, numeric) does not exist。当时第一反应是奇怪——我明明给字段加了索引，SQL单独拎出来执行也正常，怎么一放到函数里就崩？
排查了很久才发现，问题出在一个函数参数的隐式类型转换上。调用方传的是integer，函数内部声明的是numeric，而我在做WHERE条件比较时，写的是WHERE id = target_id。PostgreSQL在找不到精确匹配的等值运算符时，并不会自动做跨类型的integer = numeric比较，而是尝试寻找一个都能转过去的通用类型。如果这个转换路径不清晰，就直接报错。
这个案例特别能说明一个事：PL/pgSQL里的数据类型问题，跟普通SQL完全不同。 普通SQL里错了，顶多改一条语句；存储过程里错了，轻则函数跑不起来，重则半夜两点被运维喊起来处理跑批失败。而且在函数体内部，变量的类型声明、参数的类型匹配、返回值的类型一致性、动态SQL里的参数占位符类型，每一环都可能埋雷。
这篇文章我就用实际踩坑的经历，把PL/pgSQL里数据类型的核心知识点捋一遍。不会去讲那些文档里已经写得很细的语法，重点放在"实践里真正容易出错的地方"和"为什么这么设计"。适合所有写过PL/pgSQL但被类型问题坑过的人，也适合刚接触PostgreSQL存储过程、想少走弯路的开发者。
1. 弄清PL/pgSQL类型体系，先看它跟普通SQL的差异
PL/pgSQL不是一种独立的语言，它是PostgreSQL的过程式扩展。这意味着它的类型系统完全构建在PostgreSQL底层类型系统之上，但你写存储过程时对类型的感知，跟写普通SQL时完全不同。
1.1 变量声明是显式的，但类型推断比你想象的聪明
在普通SQL里，你基本不用声明类型，PostgreSQL会通过上下文推断列类型。但在PL/pgSQL函数里，每个变量都需要显式声明。不过有意思的是，PostgreSQL提供了两个很聪明的语法：
sql复制DECLARE
-- 直接声明类型
v_count integer;
-- 动态跟随表列类型
v_order_id orders.id%TYPE;
-- 动态跟随表结构
v_order orders%ROWTYPE;
用%TYPE意味着你不需要关心列到底是什么类型——字段改了，存储过程自动跟着变。这在维护老项目时简直是救命稻草。我记得有一次重构，某个表的主键从bigint改成了uuid，因为有一大批存储过程用了%TYPE声明，几乎没动代码就全部兼容了。而那些写死integer的函数，排查起来一个头两个大。
%ROWTYPE就更强了。它声明的是一个完整的行结构变量，你直接在函数里SELECT * INTO v_order FROM orders WHERE id = ...，然后通过v_order.customer_name访问字段。这比写十几个独立的变量声明干净得多，而且哪怕表结构新增了字段，函数内部依然能正确访问原有字段。
1.2 函数参数方向：IN、OUT、INOUT的隐式类型约束
PL/pgSQL函数的参数方向区分在类型使用上很有讲究。默认是IN，只传入不可修改；OUT参数用于返回；INOUT既传入又可修改。但很多人忽略的是：OUT和INOUT参数的最终类型，跟函数定义时的声明类型必须保持一致，PostgreSQL不会帮你做隐式转换。
来看一个常见坑。下面的写法在调用时会报错：
sql复制CREATE OR REPLACE FUNCTION get_order_total(IN order_id bigint, OUT total numeric(12,2))
RETURNS numeric(12,2) AS $$
BEGIN
SELECT amount INTO total FROM orders WHERE id = order_id;
END;
$$ LANGUAGE plpgsql;
-- 调用方式一：直接传 int
SELECT get_order_total(123); -- 某些情况可以，但遇到重载函数时可能歧义
-- 调用方式二：传字符串，大概率报错
SELECT get_order_total('123'); -- 字符串到bigint有隐式转换，通常没问题
复杂的地方在于，函数重载时PostgreSQL通过参数类型选择具体函数。如果你有两个同名函数，一个接收bigint，一个接收integer，调用时传的参数字面量恰好是整数，PostgreSQL会优先匹配更精确的类型，但某些情况下会直接报"function is not unique"。这个我在后面类型转换章节详细讲。
1.3 PL/pgSQL变量赋值时的类型对齐机制
PL/pgSQL里变量赋值遵循一条铁律：兼容的类型可以自动向上转型，不兼容的类型必须显式转换。 比如把integer赋值给bigint变量，没问题，自动扩展；把bigint赋值给integer变量，如果当前值超出整数范围，会直接抛错；把text赋值给varchar(20)变量，会根据长度截断或报错（取决于配置和值）。
最坑的是SELECT INTO语句。你把查询结果放入变量时，PostgreSQL会尝试类型对齐，但如果查询返回的是numeric而变量声明是integer，而值又有小数部分，结果是四舍五入而不是截断。这跟很多开发者预期的"报错"完全不同：
sql复制DECLARE
v_int integer;
v_num numeric(10,2);
BEGIN
SELECT 12.78 INTO v_num;
SELECT v_num INTO v_int; -- v_int 变成了 13（四舍五入），不是 12！
END;
这种静默的类型收窄很危险。数据不会报错，只是精度悄悄丢了。建议在涉及金额、数量这类对精度敏感的业务场景里，要么全程用numeric类型变量，要么在赋值前用ROUND()和TRUNC()显式格式化。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 标量类型选择的经验边界：从整数到numeric的陷阱复盘
标量类型是存储过程里最常用的，但正因为常用，反而容易忽略边界。
2.1 integer到底够不够用？什么时候必须bigint
PostgreSQL的integer是4字节，范围-2147483648到2147483647——约21亿。很多开发者在Oracle时代习惯了NUMBER无上限，到了PostgreSQL继续用integer就容易出事。
我给一个客户做数据分析平台时遇到过：他们的流水表自增主键用了integer，业务量起来后某天凌晨插入直接报integer out of range。凌晨被叫起来改表结构，从integer改成bigint，锁表加上迁移，整整折腾了两个小时。
经验之谈：在新项目里，主键和所有可能增长的ID字段直接上bigint，不要用integer。你确实可以反驳说大部分表到不了21亿行，但问题是"到不了"这个判断本身就有风险。而且PL/pgSQL里如果函数参数声明成integer，传入超过范围的数值会在层层的函数调用链里不断报错，排查成本比改表结构更高。
2.2 numeric的精度和标度：为什么金额不该用float
这是老生常谈，但我在存储过程里见过太多由于浮点计算导致的金额偏差。float8是二进制浮点，在十进制表示下会有误差——比如0.1 + 0.2不等于0.3，这在任何二进制浮点系统里都存在。如果你在PL/pgSQL里做金额累计，用float会在财务对账时产生小额但致命的差异。
正确的做法是：所有金额字段和变量使用numeric(p,s)。需要注意两点。
第一，numeric不带参数时是不限精度的，这其实不是好事。它会让计算变慢，而且因为不限制标度，1.00和1.0000在语义上相同但存储时保留的标度不同，导致UNIQUE约束和DISTINCT行为符合直觉但结果集可能意外不同。金额字段必须指定精度和标度，比如numeric(12,2)。
第二，PL/pgSQL里对numeric做除法时，标度会膨胀。1::numeric / 3::numeric得到的是0.33333333333333333333（20位小数）。如果你把这个结果存入numeric(12,2)的变量，PostgreSQL会四舍五入而不是报错。这在累加过程中可能导致微小误差被放大。稳妥的做法是在每次运算后显式ROUND()：
sql复制v_total := ROUND(v_subtotal * v_rate, 2);
2.3 文本类型的三选一逻辑：text、varchar(n)、char(n)
很多人被Oracle的CHAR习惯带偏，在PostgreSQL里也用char(n)。实际上PostgreSQL的char(n)（或者更准确说是character(n)）是固定长度，存储时右侧会补空格。这在比较和拼接时非常容易出问题——你从`char(