From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Daniel Migowski <dmigowski(at)ikoffice(dot)de> |
Cc: | Michael Nacos <m(dot)nacos(at)gmail(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: COPY support in JDBC driver? |
Date: | 2008-09-24 18:32:53 |
Message-ID: | Pine.BSO.4.64.0809241413280.6934@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Magoffin | 2008-09-24 20:44:32 | Re: very large result sets and ResultSet.relative() to jump to a desired offset |
Previous Message | Kris Jurka | 2008-09-24 18:24:16 | Re: COPY support in JDBC driver? |