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