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