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
In response to
pgsql-jdbc by date
|Next:||From: Matt Magoffin||Date: 2008-09-24 20:44:32|
|Subject: Re: very large result sets and ResultSet.relative() to jump
to a desired offset|
|Previous:||From: Kris Jurka||Date: 2008-09-24 18:24:16|
|Subject: Re: COPY support in JDBC driver?|