> Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Right -- IMHO what we should be doing is reject any input to chr() which > > is beyond plain ASCII (or maybe > 255), and create a separate function > > (unicode_char() sounds good) to get an Unicode character from a code > > point, converted to the local client_encoding per conversion_procs. > > Hm, I hadn't thought of that approach, but another idea is that the > argument of chr() is *always* a unicode code point, and it converts > to the current encoding. Do we really need a separate function?
To be honest, I don't really see why we need to rush to add such Unicode(I assume we are reffering to "Unicode" as ISO 10646) specialized functions at this point. Limiting chr() to ASCII range is enough, I think. BTW, every encoding has its own charset. However the relationship between encoding and charset are not so simple as Unicode. For example, encoding EUC_JP correponds to multiple charsets, namely ASCII, JIS X 0201, JIS X 0208 and JIS X 0212. So a function which returns a "code point" is not quite usefull since it lacks the charset info. I think we need to continute design discussion, probably targetting for 8.4, not 8.3. -- Tatsuo Ishii SRA OSS, Inc. Japan ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
