升级JDBC驱动程序后,Postgres中到整数的隐式类型转换失败



我的应用程序目前使用Postgres 8.2 JDBC驱动程序(带有Postgres 820数据库),但我们正在升级到Java 7和JDBC 4驱动程序,目前是9.2-1002版本。最终的配置将是JDBC 9.2驱动程序和Postgres 8.2数据库。

在我们的一个触发器函数中抛出了一个异常,只有在使用9.2驱动程序运行时才会发生。这是另一个表上的ON UPDATE触发器。触发器有效地做到了:

DECLARE
mytime bigint;
BEGIN
SELECT INTO mytime EXTRACT(EPOCH FROM current_timestamp(3))*1000;
UPDATE resource SET lastmodified=mytime WHERE id=NEW.resource_id;
END

resource.lastmodified列被定义为类型BIGINT。

发生的SQL错误是:

ERROR: invalid input syntax for integer: "1355248911435.9998"
Where: PL/pgSQL function "f_modify_resource" line 4 at SQL statement;

显然,错误在SELECT INTO行;这里应该有一个演员阵容。然而,我想知道为什么该语句在8.2 JDBC驱动程序中成功,而在9.2驱动程序中失败,而其他什么都没有改变?既然触发器代码在数据库中运行,那么这一切对JDBC驱动程序不应该是透明的吗?我原以为PostgreSQL会继续在这里进行隐式转换,但现在似乎已经停止了。

我尝试过在JDBC连接URL上设置compatible=8.2,但也没有效果。

编辑以下是使用9.2-1002.jdbc4驱动程序运行时语句日志中的输出(我可以确认,这至少发生在9.0驱动程序之前,可能更早):

STATEMENT:  UPDATE message SET hastext='true' WHERE rid='2-1355323570239' AND mid='1-1355329102968'
ERROR:  22P02: invalid input syntax for integer: "1355329102985.0002"
CONTEXT:  PL/pgSQL function "f_modify_resource" line 4 at SQL statement
LOCATION:  scanint8, int8.c:137

f_modify_resource函数由message表上的ON UPDATE触发器运行,其主体与上面给出的完全相同。第4行对应于SELECT INTO语句。我可以确认,EXTRACT(EPOCH...)确实返回了double precision,而且它确实应该返回。

使用8.2(jdbc4和jdbc3)驱动程序时,不会发生此错误,并且语句处理正确。

检查JDBC驱动程序是否正在设置*extra_float_digitals*。发布说明称,截至8.3-dev602,连接时设置为"2",而通常默认为零。我无法重现你的行为(我只能用9.1和9.2来测试)。然而,我可以做到:

postgres=# set extra_float_digits = 2;
SET
postgres=# select extract(epoch from current_timestamp(3));
date_part      
--------------------
1355346251.7550001
(1 row)
postgres=# select extract(epoch from current_timestamp(3));
date_part      
--------------------
1355346253.1619999
(1 row)

当乘以1000并分配给BIGINT时,我不会让它失败,但这可能是8.2特定的,所以您必须使用9.2驱动程序进行测试,并在完成连接后,但在运行失败的查询之前,显式运行语句SETextra_float_digitals=0。

最新更新