Andrew Dunstan wrote: > > The attached patch is intended to ensure that chr() does not produce > invalidly encoded data, as recently discussed on -hackers. For UTF8, we > treat its argument as a Unicode code point; for all other multi-byte > encodings, we raise an error on any argument greater than 127. For all > encodings we raise an error if the argument is 0 (we don't allow null bytes > in text data). The ascii() function is adjusted so that it remains the > inverse of chr() - i.e. for UTF8 it returns the Unicode code point, and it > raises an error for any other multi-byte encoding if the aregument is > outside the ASCII range. I have tested thius inverse property across the > entire Unicode code point range, 0x01 .. 0x1ffff.
Hmm, is this what we had agreed? I'm not sure I like it; if I'm using chr() to produce characters, then the application is going to have to worry about server_encoding in order to find the correct parameter to pass to chr(). What I thought was the idea is that chr() always gets an Unicode code point, and it converts the character to the server_encoding. If the character cannot be converted, then it raises an error. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
