| 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: | Whole Thread | Raw Message | 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? |