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? 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