Re: patch: streaming of bytea parameter values

On Sat, 22 May 2004, Oliver Jowett wrote:

> > Fixing this is difficult
> > because you cannot simply throw an Exception if you hit the end of stream
> > before the specified length because you can't just bail out when streaming
> > data as that will leave the PGStream in a confused state.  You've got to
> > get it back to a known state and do so without the query succeeding.
> >
> > Another problem along this line is that the InputStream given could throw
> > an IOException when being read and the same unknown state problem would
> > result.
>
> My V3 patches handle these cases by closing the connection entirely &
> throwing an exception (i.e. providing a short stream or throwing
> IOException is a fatal error). This seemed better than silently padding
> with bogus data.
>
> I don't see that either case is a "normal" case we should be supporting
> -- we just need to be sure we clean up properly.
>

I don't consider abandoning the connection "cleaning up properly."  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.

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?

Kris Jurka