Re: setBinaryStream can abandon connection

Kris Jurka wrote:

> This isn't ideal because it doesn't actually force a backend error so it 
> is possible to issue a commit later that will succeed instead of failing, 
> but I still think it's better than the current behavior.  I suppose we 
> could deliberately introduce a syntax error or something if in not in 
> autocommit mode.

My gut feeling is that this is a bad idea, but I guess that given you're 
not actually Executing the portal, and the driver is throwing an error 
to the application, then there's not a huge risk of the app missing the 
error.

I think we have a secondary problem here in that we've seen at least one 
instance where app code passes Integer.MAX_VALUE as the length argument 
when it does not know the actual length beforehand. a) we are going to 
overflow a signed 32-bit int for the Bind message's length and b) even 
if we have a large-but-not-too-large length, isn't the backend going to 
run out of memory if we pass that on directly?

We should probably fix (a) at a minimum. For (b) we may just have to let 
the backend complain and abandon the connection, unless we want to set 
some arbitary limit on stream length.

> Finally do we need a special -1 length argument to tell the driver we 
> don't know the length.  This will force a copy of the stream instead of 
> the current direct streaming to the backend, but a memory hog is better 
> than not working at all.

That's a nonstandard extension though.. I don't really see the point, 
given that the app can just buffer internally anyway. The only win would 
be that we wouldn't need to clone the bytearray as you need to with 
setBytes(). The app can get the same effect right now by buffering to a 
bytearray/ByteArrayInputStream before calling setBinaryStream().

Are there existing apps that pass -1?

-O