PostgreSQL COPY FROM BINARY报错"literal carriage return found in data"及函数问题咨询

咱们先拆解下你遇到的问题根源：你之前的导出函数里，是把UUID转成带单引号的字符串字面量来导出的，相当于存的是UUID的文本形式（还带了单引号），而不是UUID原生的二进制格式。当后续用COPY FROM BINARY读这个文件时，PostgreSQL试图把文本类型的二进制数据解析成UUID，过程中就会误判某些字节为回车符，直接抛出错误。

具体修复方案 #

直接修改你的导出函数，确保导出的是UUID原生类型的二进制数据，同时用更安全的参数化写法避免字符串拼接坑：

优化后的函数代码 #

CREATE OR REPLACE FUNCTION ECRS."MIGRATION.DBF_COPY_TO"(file_name VARCHAR(500)) 
RETURNS INTEGER AS $$ 
DECLARE 
    iniPath varchar(500) = file_name || '/Ini.dat'; 
    researchIdToCopy uuid; 
BEGIN 
    SELECT R.RESEARCHID 
    FROM ECRS.RESEARCH R 
    WHERE R.NAME = 'BADANIE_TESTOWE' 
    INTO researchIdToCopy; 
    
    -- 用参数化EXECUTE传递变量，既保证类型正确又避免SQL注入
    EXECUTE 'COPY (SELECT $1) TO $2 WITH BINARY' 
    USING researchIdToCopy, iniPath; 
    
    RETURN 1; 
END; 
$$ LANGUAGE plpgsql;

为啥这么改就行？ #

• 参数化查询避坑：之前用字符串拼接把UUID转成了文本，现在直接用USING传递UUID类型变量，PostgreSQL会导出UUID原生的二进制格式，而不是文本的二进制表示。
• 类型匹配不踩雷：后续用COPY FROM BINARY导入时，目标列如果是UUID类型，就能直接匹配解析，不会再出现回车符误判的问题。

额外提醒 #

1. 确认导入时的目标列类型必须是UUID，类型不匹配还是会出问题；
2. 检查下PostgreSQL进程对导出文件的路径有没有读写权限，权限不够也可能引发奇怪的解析错误。

内容的提问来源于stack exchange，提问作者Lukasz