Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] ... GB18030 - NO MATCH
[EMAIL PROTECTED] ... GB18030 - NO MATCH
[EMAIL PROTECTED] ... GB18030 - NO MATCH
zh_CN.GBK ... GBK - NO MATCH
[EMAIL PROTECTED] ... GBK - NO MATCH
[EMAIL PROTECTED] ... GBK - NO MATCH
[EMAIL PROTECTED] ... 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
