pg_duckdb项目中无符号整数类型的处理优化

在pg_duckdb项目中，开发者最近解决了一个关于无符号整数类型转换的重要问题。该项目作为PostgreSQL和DuckDB之间的桥梁，需要处理两种数据库系统间数据类型的转换问题。

问题背景

在PostgreSQL中，整数类型主要包括有符号的INT2、INT4和INT8，分别对应16位、32位和64位整数。而DuckDB则支持更丰富的整数类型，包括无符号的UTINYINT、USMALLINT和UINTEGER。当用户尝试通过pg_duckdb读取包含无符号整数的Parquet文件时，系统会抛出类型转换错误。

技术实现方案

项目团队通过修改quack_types.cpp文件中的类型转换逻辑来解决这个问题。主要修改包括：

1. 类型映射扩展：在GetPostgresDuckDBType函数中，新增了对DuckDB无符号整数类型到PostgreSQL整数类型的映射关系：

   • UTINYINT映射到INT2OID
   • USMALLINT映射到INT4OID
   • UINTEGER映射到INT8OID

2. 值转换处理：在ConvertDuckToPostgresValue函数中，针对每种整数类型增加了对无符号类型的特殊处理：

   • 对于INT2OID目标类型，检查源类型是否为UTINYINT，并进行适当的类型转换
   • 对于INT4OID目标类型，检查源类型是否为USMALLINT
   • 对于INT8OID目标类型，检查源类型是否为UINTEGER

技术细节

这种转换方案采用了安全的类型提升策略，将较小范围的无符号整数转换为较大范围的有符号整数，确保不会发生数据截断或溢出。例如：

• 8位无符号整数(0-255)转换为16位有符号整数
• 16位无符号整数(0-65535)转换为32位有符号整数
• 32位无符号整数(0-4294967295)转换为64位有符号整数

这种处理方式既保证了数据完整性，又兼容了PostgreSQL的类型系统限制。

实际效果

经过修改后，系统现在可以正确处理包含无符号整数的Parquet文件。例如，一个包含UTINYINT(255)、USMALLINT(65535)和UINTEGER(4294967295)的测试文件能够被正确读取并显示结果。

注意事项

开发者还注意到，在PostgreSQL环境中使用文件路径时，相对路径的处理可能与预期不同。这是因为PostgreSQL服务器进程的工作目录通常与客户端工具(如psql)不同，这是PostgreSQL安全模型的一部分。

这个改进显著增强了pg_duckdb在处理不同数据源时的兼容性，特别是对于那些使用无符号整数类型的Parquet文件。