Re: setCharacterStream(int, Reader)

Can you create a pull request against pgjdbc ?

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

On 20 October 2016 at 16:20, Brad DeJong <Brad(dot)Dejong(at)infor(dot)com> wrote:

> Hi,
>
>
>
> I've been subscribed to the list for about a year now, but this is my
> first post.
>
>
>
> I pushed some code to https://github.com/bd-infor/pgjdbc that implements
> the JDBC 4.1 PreparedStatement.setCharacterStream(int, Reader) API and I
> am asking for feedback.
>
>
>
> The implementation builds on work done by Alexis Meneses in pull request
> "Support for setBinaryStream with unknown length #220".
> https://github.com/pgjdbc/pgjdbc/pull/220
>
>
>
> 1) I did not add a jdbc41 counterpart to Alexis' org/postgresql/test/jdbc4/BinaryStreamTest.java.
> It is not clear to me if there is a character set requirement for the test
> database that is used by the pgjdbc tests that are run by "mvn package"?
> Many of the interesting test cases for Reader -> UTF-8 stream involve
> surrogate pairs which would require the test db to be UTF-8.
>
>
>
> 2) At present, there is no pgjdbc/src/test/java/org/postgresql/util
> directory. As a possible solution for item 1, I wrote a JUnit test that
> uses surrogate pairs directly against ReaderInputStream. It didn't seem
> appropriate to add it to the jdbc41 directory and I also didn't feel
> comfortable arbitrarily creating a new directory so I didn't push it with
> the other changes.
>
>
>
> 3) In addition to passing a Reader to setCharacterStream(), these changes
> allow you to pass a UTF-8 stream by calling PgPreparedStatement.setObject(int,
> Object, int, int) with Types.LONGVARCHAR. I'm testing the Types.LONGVARCHAR
> case with "if (in instanceof InputStream)", but it feels a bit kludgy. Any
> suggestions for a better way of tagging UTF-8 streams would be welcome. I
> considered adding a UTF8InputStream interface (or annotation), but having
> to subclass or wrap FileInputStream as a UTF8FileInputStream also seems
> kludgy.
>
>
>
> 4) setObject(int, Object, int, int) is also the one spot where I see the
> possibility of a backwards compatibility problem (if someone was calling
> setObject(..., myInputStream, LONGVARCHAR, ...) and had a working
> toString() that converted the stream to a String as opposed to using the
> default Object.toString()).
>
>
>
> Thanks,
>
> Brad DeJong
>
> www.infor.com
>