修改字段类型后报“cached plan must not change result type”错误，根本原因是JDBC预编译计划缓存中旧执行计划的返回类型（如varchar）与新字段类型（如text）OID不匹配，PostgreSQL拒绝复用；需重启应用、清空连接池或升级驱动启用preferQueryMode=simple。
修改字段类型后存储过程报错：cached plan must not change result type
PostgreSQL 中修改 varchar 到 text 看似安全，但实际可能触发 JDBC 驱动的预编译计划缓存失效。错误信息 ERROR: cached plan must not change result type（SQL state 0A000）不是数据库拒绝执行，而是客户端（如 Spring JDBC）复用了一个旧的执行计划，而该计划假设字段返回的是 varchar 类型，现在却变成 text —— PostgreSQL 认为二者虽存储一致，但类型 OID 不同，属于“结果集结构变更”，强制拒绝重用。
常见于以下场景：
- 应用使用了 MyBatis +
#{}占位符，且未配置useServerPrepStmts=false - 连接池（如 HikariCP）开启了 PreparedStatement 缓存，而表结构变更后未清理连接
- 同一连接反复执行相同 SQL，第一次在改字段前，第二次在改字段后
临时缓解方式是重启应用或清空连接池；根治需在 DDL 后主动使相关连接失效，或升级 PostgreSQL JDBC 驱动到 42.6.0+ 并启用 preferQueryMode=simple。
Oracle 存储过程中引用列名报 ORA-00904：invalid identifier
错误 ORA-00904: "REC"."JOB_START_TIME": invalid identifier 表明存储过程里用了别名 REC，但对应表/视图中根本不存在 JOB_START_TIME 这个列。这不是语法写错，而是元数据不一致导致的硬性校验失败。
原因往往藏在这些地方：
- 建表时字段叫
job_start_time，但后来被重命名为start_time，而存储过程没同步更新 - 视图
REC是基于某张表创建的，但该表结构已变更，视图未重建（CREATE OR REPLACE VIEW没执行） - 动态 SQL 字符串拼接时，变量值为空或含非法字符，导致最终 SQL 实际查的是
SELECT * FROM REC这类无明确列声明的语句
查证方法：在 SQL*Plus 或 SQL Developer 中直接运行存储过程里出错那句 SQL，把 REC 替换成真实表名，看是否能查出 JOB_START_TIME。不能，则说明字段确实不存在或别名指向错误对象。
PostgreSQL 视图依赖字段导致 ALTER COLUMN 失败
执行 ALTER TABLE ... ALTER COLUMN ... TYPE text 报错 cannot alter column type because it is used by a view or rule，说明有视图（比如 V_MM_StockInfo_Defective）在定义中显式引用了该字段，且 PostgreSQL 把这种依赖固化在系统目录 pg_depend 里，不允许破坏一致性。
不能绕过，必须按顺序处理：
- 先用
SELECT * FROM pg_depend WHERE refobjid = 'your_table'::regclass AND refobjsubid = (SELECT attnum FROM pg_attribute WHERE attname = 'c_SpecificationAndModel' AND attrelid = 'your_table'::regclass);查出所有强依赖对象 - 对每个依赖视图，执行
CREATE OR REPLACE VIEW ...，确保新定义里字段类型兼容（text可接受原varchar值） - 再执行字段类型变更；若还有函数或触发器依赖，同样要先更新它们的定义
注意：不要用 DROP VIEW + CREATE VIEW 替代 CREATE OR REPLACE，前者会丢失权限和依赖链，可能引发更隐蔽的访问问题。
SQL Server 存储过程因表结构不一致报“列名无效”
在复制（Replication）或跨库调用场景下，存储过程执行时报 列名 'xxx' 无效，大概率是发布端和订阅端表结构不一致。SQL Server 复制不是实时同步 schema，字段增删后，订阅端不会自动跟进。
验证和修复步骤很直接：
- 在订阅库运行
SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'your_table'，对比发布库输出，确认缺失字段 - 手动在订阅库补字段：
ALTER TABLE your_table ADD xxx VARCHAR(50) NULL（类型需与发布端一致） - 如果字段带默认值或约束，也得一并补上，否则后续 INSERT 可能失败
- 极端情况（如字段太多、结构差异大），可用
TableDiff.exe工具做全量比对，它比人工更可靠
这类问题容易被忽略的一点是：即使字段存在，但如果发布时没勾选该字段（在 SSMS 的“文章属性”里取消了勾选），它也不会同步到订阅端——所以光查表结构不够，还得查发布配置。
