Re: Enforcing database encoding and locale match

Tom Lane wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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(dot)GB18030(at)pinyin ... GB18030 - NO MATCH
>> zh_CN(dot)GB18030(at)radical ... GB18030 - NO MATCH
>> zh_CN(dot)GB18030(at)stroke ... GB18030 - NO MATCH
>> zh_CN.GBK ... GBK - NO MATCH
>> zh_CN(dot)GBK(at)pinyin ... GBK - NO MATCH
>> zh_CN(dot)GBK(at)radical ... GBK - NO MATCH
>> zh_CN(dot)GBK(at)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