Re: Server-side support of all encodings - Mailing list pgsql-hackers

From Ioseph Kim
Subject Re: Server-side support of all encodings
Date
Msg-id 001301c76f57$272d0c10$1e00a8c0@IDC
Whole thread Raw
In response to Server-side support of all encodings  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
At Korea, Johab code is very old encondig.
by the way, cp949 code page is really used in most environments.

Personally speaking, Johab server code set is not need.
I think that PostgreSQL supports UHC (cp949) server  code set.
This feature will be greet many Korean. :)
Unfortunately, UHC code set have character sequences less then 128 byte.

I tred to patch this problem, but this is not simply. I had gave up. :(


----- Original Message ----- 
From: "ITAGAKI Takahiro" <itagaki.takahiro@oss.ntt.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgresql.org>
Sent: Monday, March 26, 2007 11:29 AM
Subject: Re: [HACKERS] Server-side support of all encodings


>
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> > PostgreSQL suppots SJIS, BIG5, GBK, UHC and GB18030 as client 
>> > encodings,
>> > but we cannot use them as server encodings. Are there any reason for 
>> > it?
>>
>> Very much so --- they aren't safe ASCII-supersets, and thus for example
>> the parser will fail on them.  Backend encodings must have the property
>> that all bytes of a multibyte character are >= 128.
>
> But then, PG_JOHAB have already infringed it. Please see 
> johab_to_utf8.map.
> Trailing bytes of JOHAB can be less than 128.
> It's true that other server-supported encodings use only characters >= 
> 128.
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
>                http://www.postgresql.org/about/donate
> 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Server-side support of all encodings
Next
From: Galy Lee
Date:
Subject: Changing semantics of autovacuum_cost_limit