From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | mbch67(at)yahoo(dot)com |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: 8.0.0beta4: "copy" and "client_encoding" |
Date: | 2004-11-04 10:17:22 |
Message-ID: | 418A01B2.70104@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
mbch67(at)yahoo(dot)com wrote:
> Thanks Kris and Oliver for your explanations.
>
> Why I want to set the client_encoding to latin1? That's a fair
> question. Unfortunately I removed the statement following the COPY
> command to keep the posting short:
>
> SET CLIENT_ENCODING TO 'LATIN1';
> COPY temp_test FROM '/home/postgres/temp_test.dat';
>
> I want to load a latin1-encoded file using the COPY command.
Hmm. I am suprised that COPY does not let you specify the encoding of
the input file. Using client_encoding for this seems wrong: there are
some cases it can't handle, e.g. trying to load a LATIN1-encoded file
into a table that has a name that can't be represented in LATIN1.
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.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2004-11-04 10:30:56 | Re: Avoiding explicit addDataType calls for PostGIS |
Previous Message | mbch67 | 2004-11-04 07:08:43 | Re: 8.0.0beta4: "copy" and "client_encoding" |