Re: Enforcing database encoding and locale match - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Enforcing database encoding and locale match
Date
Msg-id 46FD6DE0.1060203@sun.com
Whole thread Raw
In response to Re: Enforcing database encoding and locale match  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> On Solaris I got following problematic locales:
> 
>> C                       ... 646        - NO MATCH
>> POSIX                   ... 646        - NO MATCH
>> cs                      ... 646        - NO MATCH
>> da                      ... 646        - NO MATCH
>> et                      ... 646        - NO MATCH
>> it                      ... 646        - NO MATCH
>> ja_JP.PCK               ... PCK        - NO MATCH
>> ko                      ... 646        - NO MATCH
>> no                      ... 646        - NO MATCH
>> ru                      ... 646        - NO MATCH
>> sl                      ... 646        - NO MATCH
>> sv                      ... 646        - NO MATCH
>> tr                      ... 646        - NO MATCH
>> zh.GBK                  ... GBK        - NO MATCH
>> zh_CN.GB18030           ... GB18030    - NO MATCH
>> zh_CN.GB18030@pinyin    ... GB18030    - NO MATCH
>> zh_CN.GB18030@radical   ... GB18030    - NO MATCH
>> zh_CN.GB18030@stroke    ... GB18030    - NO MATCH
>> zh_CN.GBK               ... GBK        - NO MATCH
>> zh_CN.GBK@pinyin        ... GBK        - NO MATCH
>> zh_CN.GBK@radical       ... GBK        - NO MATCH
>> zh_CN.GBK@stroke        ... GBK        - NO MATCH
> 
> Not sure what 646 or PCK are, but we don't need to worry about GB18030
> or GBK, because those aren't allowed backend encodings.


PCK is Japanese Shift-JIS encoding. (see
http://www.inter-locale.com/whitepaper/learn/learn_to_type.html)

http://en.wikipedia.org/wiki/Shift_JIS

646 looks like ISO646. I will check it.

http://en.wikipedia.org/wiki/ISO646

> 
>> The another question is what do when we know that this codeset/encoding 
>> is not supported by postgres.
> 
> I don't really see a need to worry about this case.  The proposed encoding
> will already have been checked to be sure it's one that the backend supports.
> All we need is to be able to recognize any variant spelling of the
> encodings we allow.

OK. Maybe would be good put mapping into text file (e.g. encoding.map) 
into share directory. (Similar to tz_abbrev)
    Zdenek


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Getting to 8.3 beta1
Next
From: Bruce Momjian
Date:
Subject: Re: TODO/exotic features/sql*net