I am currently cleaning up a few places where OID 0 could get used as a
parameter type (causing the backend to try to infer a type). For
example, this occurs when setObject() is passed an object that it can't
classify (not any of Integer, Boolean, PGobject, etc), or when calling
setObject() with a non-PGobject and Types.OTHER.
I think this is a bad idea: we do not have any mechanism in place to
check that the type actually matches the expected type. It also seems
quite fragile to rely on this behaviour when everything else in JDBC is
fairly strongly typed.
Another place I am less sure about is setNull(x, Types.OTHER); this
passes the NULL with type OID 0. Without this, there is no other way to
set a nonstandard-typed parameter to null. I think this is still
problematic. Consider the case where you have two functions:
foo(line)
foo(box)
Executing "SELECT foo(?)" via PreparedStatement will work fine if you
pass a non-null PGline or PGbox argument to setObject, but if you try to
setNull() then you will get ambiguity between the two functions at
execution time.
I can't see a way to fix this without a postgresql extension of some
sort. Options I can think of are:
1) PGStatement.setNull(int parameterIndex,String databaseType): sets
parameter to null with the given type.
2) PGStatement.setTypeHint(int parameterIndex,String databaseType): sets
parameter's type, only, to the given type; this is then used by later
calls to setNull().
3) PGConnection.addDataType(String type, Class klass, int sqlType):
register a new java.sql.Types value along with the type handler.
(3) seems like the least intrusive approach, but it requires that
extension types somehow decide on a unique Types value. I'm not sure if
this is practical.
-O