Re: patch: streaming of bytea parameter values

Kris Jurka wrote:
> On Sun, 23 May 2004, Oliver Jowett wrote:
>>Kris Jurka wrote:
>>
>>>I don't consider abandoning the connection "cleaning up properly."
>>
>>I don't see what isn't cleaned up by closing the connection. It seems
>>the simplest and safest way of handling this sort of error.
>
> Yes it is the simplest and safest way of doing this, but it is far from
> the user friendliest way of doing things. They want to just
> Connection.rollback() and continue. In the past we have rejected patches
> adding copy support because it had the potential of completely hosing a
> connection.

I thought the issue with V2 copy support was more that the copy stream
was mostly freeform, and as such you were at the mercy of the
application to correctly terminate it. If the protocol stream state got
hosed, you couldn't easily detect it.

This is a bit different in that we can always detect it. You never end
up with a hosed connection that the driver will try to continue using.

Being user-friendly when dealing with application errors is nice
behaviour to have, but it *is* a separate issue..

> This is more of a general problem with the JDBC driver
> in that if it throws an Exception itself it does not require a rollback
> while server generated errors do. Perhaps this should be added to the
> drivers query issuing/commit logic to refuse to proceed if the driver has
> thrown an error.

If you're talking about all the exceptions that can ever be thrown by
the driver, it sounds like unnecessary complexity to me,

It makes sense for exceptions thrown during query execution though, Are
there currently any cases where the driver can throw an exception from
query execution without invalidating the current transaction?

Also: multiple-statement queries and batch updates. Currently we always
stop execution on the first error. I'd like to keep that property. The
batch update javadoc requires that the continue-after-error behaviour be
consistent for a particular DBMS+driver.

> I would agree with this statement, but this would invalidate the wrapping
> of a byte[] in a ByteArrayInputStream because that seems to require a
> different behavior.

Oops, good point. My v3 changes will need a bugfix.

Anyway, I'm unlikely to have time to revisit this particular patch. I'll
take another look at the error path in my v3 work.

-O