Skip site navigation (1) Skip section navigation (2)

Implementing setBinaryStream(int, InputStream, long)

From: "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>
To: PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Implementing setBinaryStream(int, InputStream, long)
Date: 2012-05-29 13:45:01
Message-ID: ij35el.x5ij35el.fwaj.w17m.gnus@asuka.myrkraverk.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Hi all,

I have implemented the JDBC 4 function setBinaryStream(int, InputStream,
long) in the PreparedStatement.  It is a bit of a hack since I added
long to the ParameterList interface and StreamWrapper.  I suppose that
was a bit of an overkill.

PostgreSQL doesn't support field values larger than 1GB according to
http://www.postgresql.org/about/ so I suppose a check if the length
given is larger than Integer.MAX_VALUE and throw an exception is
reasonable.  What exception makes sense?  The Integer.MAX_VALUE is
chosen based on the underlying protocol using length values in int32.

Is there any sense in choosing a smaller value for this?

With the appropriate check, the implementation is trivial:

  preparedParameters.setBytea( parameterIndex, value, (int) length );

The V3 protocol does not allow piecewise transmission of data, so
implementing setBinaryStream( int, InputStream ) makes no sense.  Notice
the absense of the length field.

I can submit a patch once I know to deal with values that don't fit in
an int.


-- 
   Johann Oskarsson                http://www.2ndquadrant.com/    |[]
   PostgreSQL Development, 24x7 Support, Training and Services  --+--
                                                                  |
   Blog: http://my.opera.com/myrkraverk/blog/

Responses

pgsql-jdbc by date

Next:From: Dave CramerDate: 2012-05-29 18:17:09
Subject: Re: a difference of version information 9.1-902 jar and source
Previous:From: OTSUKA KenjiDate: 2012-05-29 01:14:39
Subject: Re: a difference of version information 9.1-902 jar and source

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group