tightening up on use of oid 0

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