| From: | Markus Schaber <schabios(at)logi-track(dot)com> |
|---|---|
| To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
| Cc: | pgsql-jdbc(at)postgresql(dot)org, mbch67(at)yahoo(dot)com |
| Subject: | Re: 8.0.0beta4: "copy" and "client_encoding" |
| Date: | 2004-11-05 15:03:24 |
| Message-ID: | 20041105160324.43afb9e1@kingfisher.intern.logi-track.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Hi, Oliver,
On Thu, 04 Nov 2004 10:17:22 +0000
Oliver Jowett <oliver(at)opencloud(dot)com> wrote:
> 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.
I think you're right. Except COPY from STDIN, client encoding should be
independent from COPY encoding. So I suggest that Adrian requests
backend support for this.
Greets,
Markus
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com | www.logi-track.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-11-05 15:56:25 | Re: Name Lookup Weirdness |
| Previous Message | Ulrich Meis | 2004-11-05 14:39:37 | Re: 8.0.0beta4: "copy" and "client_encoding" |