On Mon, Dec 6, 2010 at 5:48 AM, Hitoshi Harada <umi.tan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
