Skip site navigation (1) Skip section navigation (2)

Re: Enforcing database encoding and locale match

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Enforcing database encoding and locale match
Date: 2007-09-28 20:43:04
Message-ID: 18273.1191012184@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

> 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

In response to

Responses

pgsql-hackers by date

Next:From: Hannes EderDate: 2007-09-28 20:43:17
Subject: msvc >= VC7 understands __FUNCTION__
Previous:From: Zdenek KotalaDate: 2007-09-28 20:18:50
Subject: Re: Enforcing database encoding and locale match

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group