如何解决PostgreSQL time类型到Azure Data Factory的转换失败问题？

可行解决方案（按优先级排序） #

1. 修改PostgreSQL连接字符串参数 #

这是最简便的全局解决方案，无需修改单个数据集或管道：

• 打开ADF中的PostgreSQL链接服务，编辑连接配置。
• 在现有连接字符串末尾追加以下参数：

  ;TimeZone=UTC;ConvertInfinityDateTime=true;ServerCompatibilityMode=Latest
  

• 保存后测试连接，再尝试预览数据集或运行管道。
• 原理：通过指定时区参数明确time类型的转换基准，同时启用无限日期转换、强制使用最新驱动兼容模式，绕过Npgsql驱动对无时区time类型的转换bug。

2. 手动调整复制活动的列映射 #

如果连接字符串参数无效，可针对涉事列修改映射规则：

• 打开复制活动的映射标签，找到出错的time(0)列。
• 将源数据类型强制改为 String，目标数据类型保持 Time（或先设为 Varchar(10)，后续转换）。
• 若目标先存为字符串，可在复制活动后添加一个SQL执行活动，用以下语句将字符串列转为Time类型：

  UPDATE [目标表] SET [time列] = CONVERT(TIME(0), [临时字符串列]);
  ALTER TABLE [目标表] DROP COLUMN [临时字符串列];
  

3. 使用数据流动统一处理转换 #

针对多个管道的批量场景，数据流动的转换逻辑更灵活：

• 创建数据流动，源选择PostgreSQL涉事表。
• 添加派生列转换，对time列执行转换：

  toString([源time列]) -> toTime($$)
  

• 将转换后的列映射到Azure SQL目标表的Time列，运行数据流动替代原复制活动。

4. 验证PostgreSQL列的时区属性 #

虽然你无法控制PostgreSQL服务器，但可通过ADF的查询数据集验证：

• 创建一个自定义SQL数据集，执行查询：

  SELECT column_name, data_type, is_nullable, udt_name FROM information_schema.columns WHERE table_name = '你的表名' AND column_name = '你的time列名';
  

• 若返回的 udt_name 为 timetz，说明是带时区的time类型，此时需在连接字符串中指定匹配的时区参数（如 TimeZone=Asia/Shanghai）。

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