> On Wed, 24 Sep 2008, Daniel Migowski wrote:
>
> AFAIK is UTF-8 the only encoding which the driver supports, anyway.
> And the native Java encoding, too. In my opinion the API should either
> support Writers and Readers (instead of Output- and InputStream), so
> the application has to take care for the encoding itself, or the API
> should encapsulate setting an arbitrary encoding on the server side
> before the copy command, and return to the default encoding directly
> afterwards.
>
>
> Yes, the current copy patches only support *Stream which does leave
> the user exposed to encoding issues. Providing a Reader/Writer API
> doesn't support COPY ... BINARY, but I don't know how many people
> would actually use such a thing. Parallel interfaces are a
> possibility, but I'd guess people would end up using the Stream
> versions for non-binary data anyway.
>
> Does anyone have the need to do COPY BINARY?
>
> I also wonder what the encoding conversion hit is if no conversion
> needs to be done. Perhaps we should measure that before abandonding
> the Stream API?
>
> Kris Jurka
Somehow in the midst of this thread the discussion of abandoning
the Stream API seems to have come up. The Java API clearly
indicates through the java.sql package that the ResultSet Interface
has stream methods. Please continue to support the Java API JDBC.
Dana Proctor.
