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

Re: Server-side support of all encodings

From: "William ZHANG" <zedware(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Server-side support of all encodings
Date: 2007-06-25 01:56:28
Message-ID: f5n7ba$nmr$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
>> 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.

Sorry. I still cannot understand why backend encodings must have this
property. AFAIK, the parser treats characters as ASCII. So any multi-byte
characters will be treated as two or more ASCII characters. But if
the multi-byte encoding doesnot use any special ASCII characters like
single quote('), double quote(") and backslash(\), I think the parser
can deal with it correctly. A quick search in
src\backend\utils\mb\Unicode\*.map tells me that no encoding uses
single quote or double quote, but JOHAB, GBK, GB18030, BIG5, SJIS
use backslash. Since pgsql doesnot accept backslash as escape character
in identity(double quoted string) or value(single quoted string)
any more, I think the parser/scanner can process multi-bytes characters

Thanks in advance.
William ZHANG

> regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match

In response to


pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2007-06-25 03:16:23
Subject: Re: [Fwd: Re: tsearch in core patch]
Previous:From: Andrew DunstanDate: 2007-06-25 01:22:13
Subject: Re: msvc and vista fun

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