Jean-Pierre Pelletier wrote:
> With JDBC Build 309, there are now TWO DIFFERENT JAVA MAPPING OF AN SQL
> NULL INTERVAL
Yes. No need to shout :)
> myPGInterval = (PGInterval) myResultSet.getObject(i)
> sets myPGInterval to null
>
> myPreparedStatement.setObject(i,myPGInterval)
> needs myPGInterval to be set to new PGInterval() instead of null
[...]
> It would be more consistent to output a SQL null interval with
> myPreparedStatement.setObject(i, myPGInterval, SomeSpecializedType)
> or even with
> myPreparedStatement.setNull(i, SomeSpecializedType)
I considered using a new Types value, but there are a couple of problems:
- how do you allocate Types values that don't collide with future
specifications?
- the type registration interface would incompatibly change
Also, I don't see how that on its own fixes generic "table copy" code --
you still need to know you're dealing with an interval on that
particular column so you can pass the right Types value to setObject.
Perhaps it works this out via metadata. We could change the
table/resultset metadata to return the modified Types values, but that's
starting to be an invasive change that affects more than just users of
extension types.
Another approach would be to continue to use Types.OTHER, but return the
equivalent of "new PGInterval()" from getObject() when a NULL resultset
value is seen. But that leads to other problems: code that retrieves a
value via getObject() has to be aware that a non-null object might
actually mean a null column.
I'm not sure that either cure is better than the disease.
-O