Dinky项目中使用PostgreSQL数据库时文档搜索报错问题分析

问题背景

在Dinky项目1.2.0版本中，当使用PostgreSQL作为后端数据库时，系统在进行文档搜索功能时会出现SQL语法错误。该问题不仅影响文档管理模块，实际上会影响所有使用类似搜索功能的模块，包括用户管理、角色管理等。

错误现象

系统在执行搜索操作时，控制台会抛出以下错误信息：

ERROR: could not determine data type of parameter $1

错误发生在执行类似如下的SQL语句时：

select count(*) as total from dinky_flink_document a where 1 = 1 and a.name like concat('%', ?, '%')

问题根源分析

经过深入分析，这个问题源于PostgreSQL数据库对参数类型推断的特殊处理方式。在PostgreSQL中，当使用concat函数时，如果参数是预编译参数(即问号占位符)，PostgreSQL无法自动推断参数的数据类型，这与MySQL等数据库的行为有所不同。

具体来说，问题出在以下几个方面：

1. 参数类型推断：PostgreSQL在执行预编译SQL时，需要明确知道每个参数的数据类型
2. concat函数处理：在PostgreSQL中，concat函数对参数类型的处理更为严格
3. SQL方言差异：Dinky项目中原生的SQL语句是为MySQL设计的，在PostgreSQL环境下需要特殊处理

解决方案

针对这个问题，可以通过修改PostgreSQLPrepareInterceptor拦截器中的SQL转换逻辑来解决。具体修改方案如下：

在org.dinky.interceptor.PostgreSQLPrepareInterceptor类中，将原有的SQL转换逻辑：

field.set(boundSql, boundSql.getSql().replace("`", "\"").toLowerCase());

修改为：

field.set(boundSql, boundSql.getSql().replace("`", "\"").replace("concat('%', '?', '%')", "concat('%', '?::text', '%')").toLowerCase());

这个修改的核心思想是：

1. 保留原有的反引号转双引号的转换
2. 增加对concat函数中参数类型的显式声明
3. 通过?::text语法明确告诉PostgreSQL这是一个文本类型的参数

影响范围

该问题不仅影响文档搜索功能，实际上会影响所有使用类似搜索模式的模块，包括：

1. 文档管理模块
2. 用户管理模块
3. 角色管理模块
4. 其他使用selectForProTable方法进行搜索的模块

解决方案的优势

1. 兼容性：修改后的代码同时兼容MySQL和PostgreSQL数据库
2. 最小侵入：只需要修改拦截器中的一处逻辑，不影响业务代码
3. 可维护性：解决方案清晰明了，便于后续维护

实施建议

对于使用Dinky项目并遇到类似问题的用户，建议：

1. 检查项目中所有使用concat函数的SQL语句
2. 确保在PostgreSQL环境下所有参数都有明确的类型声明
3. 考虑使用数据库方言适配层来处理不同数据库的语法差异

总结

PostgreSQL数据库在参数类型推断方面有其特殊性，Dinky项目在处理跨数据库兼容性时需要特别注意这一点。通过显式声明参数类型，可以有效地解决这类问题，同时保持代码的简洁性和可维护性。这个问题的解决方案也提醒我们，在开发支持多数据库的应用时，需要充分考虑不同数据库的特性和差异。