Kris Jurka wrote:
> On Mon, 12 Jan 2004, Oliver Jowett wrote:
>
>
>>I'm still in favour of an "undefined behaviour" interpretation here.
>>There's not much benefit to application code in nailing down one
>>behaviour or the other, and leaving it undefined gives the driver the
>>flexibility to do whichever is a better implementation for the DB in
>>question.
>>
>
>
> The question that has yet been unanswered is how much taking advantage of
> the "undefined behavior" will get us. You personally seem most interested
> in the setBytes() case because it is relevent to your application and it
> can potentially be quite large. I don't know how much this would gain on
> say a Date object. For your particular problem it seems you could simply
> wrap the byte array in question inside a ByteArrayInputStream (which does
> not copy it) and use setBinaryStream which would allow the delayed reading
> of it.
Yeah, modifying the driver to support setBinaryStream better is my
second choice (the current implementation just delegates to setBytes).
Most of that work overlaps with setBytes() though, it'll be almost as
easy to do both. And wrapping the array just to have the driver unwrap
it again seems a bit perverse :)
I'm interested in the official word on this anyway since even if it's
not useful to implement for some types, it's still a correctness issue.
-O