嘿，我来帮你梳理下这个问题的排查方向！你遇到的22P02错误是PostgreSQL里典型的数据类型不匹配问题——系统收到了布尔值f（也就是false），但这个值要被塞进整数类型的字段/变量里，直接触发了语法错误。咱们一步步挖根源：

1. 先查函数调用时的参数传入 #

你的函数定义里financiado是int类型，但错误提示里的输入值是f（布尔值），首先要确认：

• 调用multas.insertar_cuota时，是不是把financiado参数传成了布尔值？比如写成financiado => false而不是financiado => 0？
• 检查调用该函数的上层逻辑（比如应用代码、触发器、其他SQL脚本），有没有把布尔类型的变量直接传给了整数类型的参数。很多时候是调用时的参数类型错配导致的。

2. 检查函数内部的变量赋值语法 #

看你贴的代码片段里有这么一行：

PERFORM cuota= ROUND(importe_total/cant_cuota) ,diferenci...

这里有个关键错误：PERFORM不能用来给变量赋值！它是用来执行不需要返回结果的SQL语句（比如INSERT/UPDATE）的。你写的cuota= ROUND(...)会被PostgreSQL当成一个比较操作——判断cuota是否等于ROUND(...)的结果，返回布尔值t或f。如果后续代码把这个布尔值当成整数来用，就会触发你看到的22P02错误。

正确的变量赋值应该用:=或者SELECT ... INTO：

-- 修正后的赋值写法
cuota := ROUND(importe_total::numeric / cant_cuota);
diferencia := importe_total - (cant_cuota * cuota);

另外注意：importe_total和cant_cuota都是整数，直接做除法会取整，转成numeric再ROUND能得到更准确的结果。

3. 确认目标表的字段类型 #

既然是INSERT操作，要检查你插入的目标表（比如multas下的表）里的字段类型：

• 有没有把整数类型的字段，不小心插入了布尔值？
• 反过来，有没有把布尔类型的字段当成整数来处理？比如表中某个字段是boolean，但你在INSERT时传了整数，或者反之。

4. 排查动态SQL（如果函数里用到的话） #

如果函数内部有EXECUTE动态拼接SQL的逻辑，要检查拼接的内容：

• 有没有把布尔变量直接拼进了需要整数的位置？比如动态SQL里引用了布尔值，没有转换成1（true）或0（false），导致最终插入的SQL里出现了f，触发类型错误。

快速验证小技巧 #

可以先单独测试函数里的逻辑片段，比如把赋值语句单独拿出来执行，看是否会产生布尔值；或者在函数里加RAISE NOTICE输出变量的值，比如：

RAISE NOTICE 'cuota的值是: %, 类型是: %', cuota, pg_typeof(cuota);

这样能快速定位哪个变量出现了意外的布尔值。

内容的提问来源于stack exchange，提问作者Martín Martinez