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.
> 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.
regards, tom lane
