pandas to_sql使用自定义psql_insert_copy通过COPY插入时出现psycopg2错误

• pandas默认to_sql()走参数化逐行提交路径时，psycopg2会对传入值做隐式类型兼容转换。自定义psql_insert_copy走PostgreSQL原生COPY批量导入时，直接读取序列化后的CSV纯文本流导入，PostgreSQL不会对导入文本做隐式类型转换。
• 触发场景：DataFrame的整数列存在NaN空值时，pandas会自动将整列类型提升为float64，序列化到CSV流中就会出现"3.0"这类带小数后缀的整数字符串，匹配目标表的integer类型列时就会触发语法错误。

• 方案1：调用to_sql()前，将存在空值的整数列转换为pandas原生可空整数类型，从根源避免整列被提升为float。示例代码：

  # 转换为可空Int64类型，序列化CSV时不会附带.0后缀
  df[integer_col_list] = df[integer_col_list].astype(pd.Int64Dtype())
  

  该类型序列化CSV时，空值会输出为COPY可识别的空字段，整数值直接输出整数字面量，完全适配COPY的解析规则。
• 方案2：如果业务场景必须保留float类型的列定义，可在自定义psql_insert_copy函数生成CSV流后，对纯整数值的文本做预处理，去掉.0后缀。修改位置在CSV流生成完成、执行COPY之前：

  s_buf.seek(0)
  csv_content = s_buf.read()
  # 替换CSV中带.0后缀的整数字段为适配integer类型的格式
  processed_content = csv_content.replace('.0,', ',').replace('.0\n', '\n')
  # 重置流位置供COPY读取
  s_buf.seek(0)
  s_buf.truncate()
  s_buf.write(processed_content)
  s_buf.seek(0)
  

  注意：该预处理方式仅适用于目标整数列不存在真实有效小数值的场景，若列允许小数存储，不可全局使用字符串替换。
• 方案3：若列本身存在混合整数、小数值的场景，可调整COPY导入流程，先将数据导入到文本类型的临时表，导入完成后通过SQL语句做显式类型转换写入正式表，该方案改造量较大，优先推荐前两种轻量方案。

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