From: | mbch67(at)yahoo(dot)com |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: 8.0.0beta4: "copy" and "client_encoding" |
Date: | 2004-11-05 08:19:32 |
Message-ID: | fe065ce.0411050019.464d6929@posting.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
> I suppose that in the absence of backend support for this, we could add
> some URL parameter that allows client_encoding to be changed, with
> suitably dangerous warnings around using it. Then you can temporarily
> flip client_encoding to LATIN1 for the duration of the COPY, and revert
> it to UNICODE afterwards.
>
To me a temporarly fix is not really the solution. Shouldn't there be
done some more investigations first, e.g.
1. I set LATIN1 as the database (postgresql.conf) default client
encoding. Why does COPY, executed via JDBC not use the right encoding?
=> To me it seems to be a backend problem. Should this be address in
another posting list?
2. Was the decision to disable the "SET CLIENT_ENCODING" command
really a good idea? What about if I am running a server using UNICODE
to store text, my default client encoding is LATIN1 and I want to
import a Korean encoded text file using COPY via JDBC? There is no way
to tell COPY what encoding the input file based on.
In order to be compliant with PSQL I suggest to reactivate the
disabled "SET CLIENT ENCODING" for JDBC.
From | Date | Subject | |
---|---|---|---|
Next Message | Holger Klawitter | 2004-11-05 13:42:32 | Name Lookup Weirdness |
Previous Message | Kris Jurka | 2004-11-04 17:50:47 | Re: |