Re: the IN clause saga

>
>
>>>Option 3: make setObject(n, Collection [, type]) expand to an IN clause.
>>>
>>>+ no new methods or types needed
>>>- must assume that the contents of the collection use the default type
>>>mapping
>>>  if a type is not provided
>>>
>>>
>>>
>>You can require the type to be provided.
>>
>>
>
>Hmm, so what does setObject with no type do in that case? Also see the next
>point.
>
>
It will throw an exception - "Unrecognized parameter type: " +
Object.getClass().getName ()

>
>
>>>- if a type is provided and we apply it to the *components* of the
>>>  collection, this breaks the general getObject() interface of "bind this
>>>  object interpreting it as this particular type".
>>>
>>>
Well... this "general interface" is *by implication* only. It is not
defined this way in the spec, it is not documented to always work this way.
So, you just *assume*, that this is the general interface... It doesn't
have to be like that... Certainly not at the cost of valuable
functionality...

Dima.

P.S. Actually, in light of that previous message about 7.4 support for
arrays in the in clause, this whole discussion seems to be moot :-)
It seems to me that just setArray () should then work, without any
special handling by the driver... Isn't it the case?