Dave Cramer <pg@fastcrypt.com> writes:
> First of all thanks for the effort, and secondly welcome to the
> ambiguity of JDBC.
>
> Looking at QueryExecutorImpl.java PSQLException is thrown for errors
> in executing the protocol.
> Integer.MAX_VALUE seems like a very large number but if the protocol
> supports it we should use it. The user on the other hand may want to
> reconsider.
Based on the following protocol description of bind messages
Next, the following pair of fields appear for each parameter:
Int32
The length of the parameter value, in bytes (this count does not
include itself). Can be zero. As a special case, -1 indicates a
NULL parameter value. No value bytes follow in the NULL case.
Byte(n)
The value of the parameter, in the format indicated by the
associated format code. n is the above length.
I chose Integer.MAX_VALUE. Though by this time the message is already
wrapped in a header with total length given in Int32 so the context does
not allow Integer.MAX_VALUE parameters.
Is there a reason to check for negtive long values too?
This is how the function looks with the attached patch (edited to fit in
80 columns).
public void setBinaryStream(int parameterIndex,
InputStream value, long length) throws SQLException
{
if (length > Integer.MAX_VALUE)
throw new PSQLException(GT.tr
("Object is too large to send over the protocol."),
PSQLState.NUMERIC_CONSTANT_OUT_OF_RANGE);
preparedParameters.setBytea(parameterIndex, value, (int)length);
}
I am not sure if the message is clear enough, nor whether the SQL state
constant is appropriate. Comments?
--
Johann Oskarsson http://www.2ndquadrant.com/ |[]
PostgreSQL Development, 24x7 Support, Training and Services --+--
|
Blog: http://my.opera.com/myrkraverk/blog/
