From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - file_fdw |
Date: | 2010-12-06 14:08:42 |
Message-ID: | AANLkTikxAPzhERpP0OO6BxqXdV+g79CKMcrqusdZAaYj@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 6, 2010 at 5:48 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> I think it is better to add encoding option to FileFdwOption. In the
> patch the encoding of file is assumed as client_encoding, but we may
> want to SELECT from different-encoded csv in a query.
>
> Apart from the issue with fdw, I've been thinking client_encoding for
> COPY is not appropriate in any way. client_encoding is the encoding of
> the statement the client sends, not the COPY target which is on the
> server's filesystem. Adding encoding option to COPY will eliminate
> allowEncodingChanges option from JDBC driver.
Yeah, this point has been raised before, and I agree with it. I
haven't heard anyone who speaks a European language complain about
this, but it seems to keep coming up for Japanese speakers. I am
guessing that means that using multiple encodings is fairly common in
Japan. I typically don't run into anything other than UTF-8 and
Latin-1, which are mostly compatible especially if you're an English
speaker, but if it weren't for that happy coincidence I think this
would be quite annoying.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2010-12-06 14:37:06 | Re: Suggesting a libpq addition |
Previous Message | Robert Haas | 2010-12-06 13:57:54 | Re: WIP patch for parallel pg_dump |