oracle、sql server、postgresql处理lob必须严格区分类型路径：oracle需全程用clob变量并to_clob()转换，sql server须分块.write()避免隐式截断，postgresql需用oid字段存lo oid且事务内操作。

直接用 VARCHAR2 或 varchar(max) 变量拼接、赋值、传参，基本都会 silently 截断或报错——这不是配置问题，是类型路径没走对。

Oracle 存储过程里必须全程用 CLOB 变量

哪怕字段已是 CLOB，只要中间变量声明成 VARCHAR2，就可能在拼接、EXECUTE IMMEDIATE、LISTAGG 返回值等环节被截断，且不报错。

• 声明变量时写 my_text CLOB;，别用 my_text my_table.text_col%TYPE（可能继承旧 VARCHAR2 定义）
• 字符串字面量拼接必须每个都套 TO_CLOB()：my_text := TO_CLOB('a') || TO_CLOB('b') || TO_CLOB('c');
• LISTAGG 结果必须包 TO_CLOB()：SELECT TO_CLOB(LISTAGG(name, ',') WITHIN GROUP (ORDER BY id)) FROM t;
• 动态 SQL 中插入 CLOB，不能拼字符串，要用绑定变量：EXECUTE IMMEDIATE 'INSERT INTO t(c) VALUES (:1)' USING my_text;

SQL Server 存储过程别信 varchar(max) 能直赋

表面支持 SET @blob = @data，但协议层、隐式转换、中间计算会悄悄截断——尤其客户端传入超 4MB 或 T-SQL 内拼接时。

• 安全写法是分块覆盖：UPDATE t SET blob_col.WRITE(@chunk, @offset, LEN(@chunk)) WHERE id = @id;
• 避免 @a + @b + @c 拼接，中间结果可能被隐式转成 8000 字节 varchar
• 客户端上传大文本，优先走参数绑定，别拼进 SQL 字符串里
• 读取时慎用 CAST(blob_col AS varchar(max))，超长内容可能被截或报错，直接用原字段参与运算

PostgreSQL 的 LO 不是 bytea，混用就存失败

想存大文本进 lo（大对象），就不能往 bytea 字段里塞；反过来，往 bytea 里存大文本，也不能用 lo_from_bytea() 返回 OID。

• 业务表字段类型必须是 oid（不是 int4），才能存 lo_from_bytea(0, $1) 返回的 OID
• 存完必须 COMMIT，否则 LO 对象会被自动清理
• 读取用 lo_get(oid)，它一次性加载全部内容进内存——>100MB 小心 OOM
• 别在事务里反复调 lo_from_bytea() 生成新 OID，旧 LO 不会自动释放，得手动 lo_unlink()

最易忽略的是：Oracle 的 LOB 定位器一旦 SELECT ... FOR UPDATE 出来，就必须在同一个事务里写完；SQL Server 的 .WRITE() 偏移量必须精确等于当前长度；PostgreSQL 的 lo_get() 没流式接口，全量加载是唯一选择。