Re: SQL/MED - file_fdw

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

In response to

Browse pgsql-hackers by date

  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