Re: use of OID.Unknown

On Tue, 8 Nov 2005, Dave Cramer wrote:

> The question is still valid. This is a usability issue which will affect
> many users who switch from 7.4 to 8.x
>
> I strongly suspect that the server will release a minor revision very
> soon, which would allow us the opportunity to make this change.
>

I don't think this is a simple switch we should throw in a minor revision
either. The real source of our problems is that for performance reasons
we never issue a Describe Statement protocol message.

Right now we Parse/Bind/Describe/Execute/Sync never worrying about what
types the
server actually wants because we've already resolved and specified them
from the setXXX methods (except for timestamp recently). As you note this
does generate some issues, especially with pg types that don't have a Java
equivalent, for example inet. We've also seen issues where Ken Geis was
assuming that he could get binary results for any type. He couldn't and
couldn't even know that was going to happen and request binary instead
because the s no Describe issued.

To correctly infer types we should Parse/Describe/Sync then
Bind/Execute/Sync. This would allow us to use the unknown oid, but still
correctly convert provided Java types to the desired server types and in
general would give us a lot more flexibility. The drawback is of course
that it'll be slower because we're doing two network trips instead of one.

Finally there are a few cases where the server simply cannot resolve the
provided type and bails out with an error message. If using the JDBC
setXXX provided types, these work. Consider "SELECT ? IS NULL" or an
overloaded function that cannot be resolved.

Kris Jurka