Home/ Questions/Q 8984099
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T21:00:34+00:00

My application currently uses the Postgres 8.2 JDBC driver (with Postgres 8.2 database), but

  • 0

My application currently uses the Postgres 8.2 JDBC driver (with Postgres 8.2 database), but we are upgrading to Java 7 and the JDBC 4 driver, which is currently the 9.2-1002 release. The ultimate configuration will be the JDBC 9.2 driver with Postgres 8.2 database.

There is an exception being thrown in one of our trigger functions, and it only occurs when running with the 9.2 driver. This is an ON UPDATE trigger on another table. The trigger effectively does:

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

The resource.lastmodified column is defined as type BIGINT.

The SQL error that occurs is:

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

Obviously the error is in the SELECT INTO line; there should be a cast to BIGINT here. However, I’m wondering why the statement succeeds with the 8.2 JDBC driver, but fails with the 9.2 driver when nothing else has changed? Since the trigger code runs inside the database, shouldn’t this all be transparent to the JDBC driver? I thought that PostgreSQL would continue to do an implicit cast here, but it seems to have stopped.

I’ve tried setting compatible=8.2 on the JDBC connection URL with no effect also.

Edit
Here’s the output in the statement log when running with the 9.2-1002.jdbc4 driver (and I can confirm that this occurs at least as far back as the 9.0 driver, possibly earlier):

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

The f_modify_resource function is run by an ON UPDATE trigger on the message table, and its body is exactly as given above. Line 4 corresponds to the SELECT INTO statement. I can confirm that the EXTRACT(EPOCH...) does indeed return a double precision, and it should indeed.

With the 8.2 (jdbc4 and jdbc3) driver, this error does not occur, and statements process correctly.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Check to see if the JDBC driver is setting *extra_float_digits*. The release notes say that as of 8.3-dev602 it is set to ‘2’ upon connection whereas it normally defaults to zero. I can’t reproduce your behavior (all I have is 9.1 and 9.2 to test with). However, I can do this:

    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)

    I can’t get this to fail when multiplying by 1000 and assigning to a BIGINT, but that may be something that is 8.2-specific, so you’ll have to test by using the 9.2 driver and explicitly running the statement SET extra_float_digits = 0 after you finish connecting, but before running the query that’s failing.

    • 0