| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: UTF8 with BOM support in psql |
| Date: | 2009-11-17 17:03:10 |
| Message-ID: | 1258477390.10724.25.camel@fsopti579.F-Secure.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On tis, 2009-11-17 at 09:31 +0900, Itagaki Takahiro wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
> > OK, I think the consensus here is:
> > - Eat BOM at beginning of file (as you implemented)
> > - Only when client encoding is UTF-8 --> please fix that
>
> Are they AND condition? If so, this patch will be useless.
> Please remember \encoding or SET client_encoding appear
> *after* BOM at beginning of file.
Presumably, if you have editors throwing in BOM marks without asking,
you have an environment where either
a) You can set the client encoding to UTF8 in the environment, so it
applies by default, or
b) The server encoding is UTF8, so the client encoding will default to
that.
Together, that should cover a lot of cases. Not perfect, but far from
useless.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-11-17 17:03:18 | Re: plpythonu DO support (inline call handler) |
| Previous Message | Valtonen, Hannu | 2009-11-17 16:48:36 | plpythonu DO support (inline call handler) |