Kris Jurka wrote:
> Your approach has the benefit of being
> fail-fast as adding a new function to the database suddently can't
> produce an ambiguity for Java code.
Right. The driver cannot guarantee that setNull(i,Types.OTHER) will
always be able to infer the right type. It seems safer to me to
completely disallow it than have it sometimes succeed and sometimes fail
depending on the exact state of the database. It may break older apps,
but new apps would be more robust.
General question for the list: how much code is out there that performs
one of these (equivalent) calls?
PreparedStatement.setObject(i, null);
PreparedStatement.setObject(i, null, Types.OTHER);
PreparedStatement.setNull(i, Types.OTHER);
> I don't think it's a common
> situation to have overloaded functions that get called with non-typed
> nulls, so I wanted to allow it to work as usual for non-ambiguous
> cases.
After some experimentation, it's not just overloaded functions that are
affected.
- "? IS NULL" breaks if the parameter is an untyped NULL (this was the
original issue -- in an off-list email --that made me look at this area)
- Functions taking 'anyarray' or 'anyelement' don't like untyped NULLs,
even if they are STRICT (ERROR: could not determine anyarray/anyelement
type because input has type "unknown")
I'd like to catch those errors earlier than query execution if possible.
If nothing else, it'll encourage application developers to provide
correct type info to the driver in all cases..
-O