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