On Mon, Dec 6, 2010 at 5:48 AM, Hitoshi Harada <umi.tanuki@gmail.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