Re: UTF8 with BOM support in psql

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: UTF8 with BOM support in psql
Date: 2009-11-17 00:51:26
Message-ID: 4B01F38E.1030402@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. I'll agree if the condition is
> "Eat BOM at beginning of file and <<set client encoding to UTF-8>>",
> like:
> Defining Python Source Code Encodings:
> http://www.python.org/dev/peps/pep-0263/
>

As previously discussed we should not be automagically setting the
client encoding, nor inferring it from the presence of a BOM.

As for when it can be set, unless I'm mistaken you should be able to set
it before any file is opened, if you need to, using PGOPTIONS or psql
"dbname=mydb options='-c client_encoding=utf8'". Of course, if the
server encoding is utf8 then, in the absence of it being set using those
methods, the client encoding will start as utf8 also.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-11-17 01:03:02 Re: UTF8 with BOM support in psql
Previous Message Tom Lane 2009-11-17 00:37:35 Re: UTF8 with BOM support in psql