有没有技术上的原因,不能使用JDBC CallableStatement来执行返回SETOF(特别是REFCURSOR)的PostgreSQL存储函数?根据PostgreSQL JDBC文档:
应该不使用CallableStatement接口调用返回数据集的函数,而应该使用普通的Statement或PreparedStatement接口。
除此之外,我没有看到任何理由,性能、错误相关或其他方面,为什么不应该这样做,它似乎确实有效。它似乎本质上限制了您可以对某些函数执行的操作(尤其是返回多个结果集的函数),并且在从另一个数据库移植过程中有点不舒服。我很怕忽略这个软件发布组织的明显警告,但我很想更具体地了解为什么。我确实意识到,在单个传输中服务器和客户端处理游标和结果集的方式不同,但已经将其记录为缺点。
更新:PostgreSQL 实现了一个用于函数的 CallableStatement,将调用字符串的格式转换为选择语句。因此,返回 SETOF(以及所有函数)的函数的 JDBC 执行与使用 PreparedStatement 的方式相同。
JDBC CallableStatement 是可处理输出参数的 PreparedStatement。由于返回 SETOF 的 PostgreSQL 函数不能包括输出参数,因此对于此类函数,CallableStatement 不提供任何其他功能。但是,PostgreSQL 文档不反对使用 CallableStatement 处理不包含输出参数的函数,并且目前似乎没有任何技术原因不使用 CallableStatement。
我的同事指出,这个警告已经存在很长时间了,所以它似乎是一个设计决策,而不是一个错误。虽然 CallableStatement 目前可以工作(我认为它将继续工作),但如果这是一个设计决策,就无法保证它将来会继续工作。
应该不使用CallableStatement接口调用返回数据集的函数,而应该使用普通的Statement或PreparedStatement接口。
除此之外,我没有看到任何理由,性能、错误相关或其他方面,为什么不应该这样做,它似乎确实有效。它似乎本质上限制了您可以对某些函数执行的操作(尤其是返回多个结果集的函数),并且在从另一个数据库移植过程中有点不舒服。我很怕忽略这个软件发布组织的明显警告,但我很想更具体地了解为什么。我确实意识到,在单个传输中服务器和客户端处理游标和结果集的方式不同,但已经将其记录为缺点。
更新:PostgreSQL 实现了一个用于函数的 CallableStatement,将调用字符串的格式转换为选择语句。因此,返回 SETOF(以及所有函数)的函数的 JDBC 执行与使用 PreparedStatement 的方式相同。
JDBC CallableStatement 是可处理输出参数的 PreparedStatement。由于返回 SETOF 的 PostgreSQL 函数不能包括输出参数,因此对于此类函数,CallableStatement 不提供任何其他功能。但是,PostgreSQL 文档不反对使用 CallableStatement 处理不包含输出参数的函数,并且目前似乎没有任何技术原因不使用 CallableStatement。
我的同事指出,这个警告已经存在很长时间了,所以它似乎是一个设计决策,而不是一个错误。虽然 CallableStatement 目前可以工作(我认为它将继续工作),但如果这是一个设计决策,就无法保证它将来会继续工作。