Thomas Kellerer wrote:
> No I'm not using setString() in that example. The Java code would be:
>
> Statement stmt = connection.createStatement();
> stmt.executeUpdate("INSERT INTO my_table (guid_column) " +
> " VALUES ('a0eebc999c0b4ef8bb6d6bb9bd380a11')");
>
> So it's passing a literal and is not using a PreparedStatement
That should work identically to what you're doing via psql then, so
something strange is going on. Can you put together a testcase showing
the problem?
> The Javadocs of setObject(int, Object) say:
>
> "The given argument will be converted to the corresponding SQL type
> before being sent to the database"
The "corresponding SQL type" of a java.lang.String is Types.VARCHAR.
> So I was expecting that the driver will be able to do the same
> conversion with the PreparedStatement as it is obviously happening when
> using a literal (though that conversion probably takes place on the
> server not in the driver).
If you were using a PreparedStatement (which you're not anyway) then
it's more like executing 'PREPARE foo(varchar) AS INSERT INTO ....
VALUES ($1)' -- the driver does not substitute query values inline, but
uses the server's support for providing parameters and their types
out-of-line. There is some magic in the query parser that treats string
literals more as an unknown type to be inferred from the query context,
rather than a specific type. Specifying Types.OTHER to setObject() is
the way to tell the JDBC driver that the String you passed isn't
necessarily a text type and the same type inference should be done.
-O
