Re: patch: streaming of bytea parameter values - Mailing list pgsql-jdbc

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.

>
> > With
> > the V3 protocol we have a reasonable recovery method because we will
> > detect this error at Bind time and simply not issue the Execute.  In the
> > current code's case it seems the only way to do it is to deliberately
> > introduce a syntax error to make the query fail.
>
> We'd have to insert an artificial syntax error (another Parse after the
> Bind that failed) anyway to force transaction rollback.
>
> I'm reluctant to allow the txn to continue as a) it's inconsistent with
> how other errors are handled and b) the distinction between Bind and
> Execute is a bit fuzzy. There is some portal setup work run on Bind, and
> I'm not sure if we can assume that a Bind immediately followed by a
> ClosePortal does not modify the DB in any way.

If you don't issue an Execute and the query proceeds I'd consider that a
bug in the server.  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.

> > Another issue that just came to me is what is the desired behavior for
> >
> > ByteArrayInputStream bais = new ByteArrayInputStream(new byte[1000]));
> > PreparedStatement ps = conn.prepareStatement("INSERT INTO t VALUES (?)");
> > ps.setBinaryStream(1, bais, 100);
> > ps.execute();
> > ps.execute();
> > ps.execute();
> >
> > Should each inserted row have the same values?  Should the second row get
> > the second 100 bytes and the third row get the third 100?
>
> I'm sure that there is something somewhere in the spec that says that
> the client has to keep the stream in an appropriate state until
> execution (but now I can't find it anywhere!). So I'd expect in this
> case to get bytes 0-99, 100-199, 200-299 inserted into the three rows
> respectively.

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.

>
> More fun is what happens if you do the above with addBatch() /
> executeBatch(); should that be equivalent to treating addBatch() as a
> "query execution"? What if we want to delay reading the data until the
> real batch execution?
>

Yes, the javadocs pretty much suck in determining the corner cases so I
don't know what to tell you.  Should we try to set up environments for
other databases and see what they do?  Without some investigation our
current plan of providing the safest behavior is something that can
kill any potential performance gains.

Kris Jurka