On Thu, Apr 05, 2007 at 11:52:14AM +0200, Albe Laurenz wrote:
> But isn't a simple fix for chr() and ascii(), which does not
> require a redesign, a Good Thing for 8.3 if possible? Something
> that maintains as much upward and/or Oracle compatibility as
> possible while doing away with ascii('EUR') returning 226 in UTF-8?I think the earlier expressed idea of getting chr/ascii to bail on non-ascii character isn't a bad one. I think your idea is bad in the sense that I actually need to know the encoding of the character I want to be able to use it. If I knew the encoding already, I could just use encode(). What I was thinking of was something that, irrespective of the encoding, gave me a string properly encoded with the character I want. Since AFAIK Unicode is the only character set that actually numbers the characters in a way not related to the encoding, so it would seem useful to be able to give a unicode character number and get a string with that character... So your implemntation is simply: 1. Take number and make UTF-8 string 2. Convert it to database encoding. > And I think - correct me if I am wrong - that conversion between > character and integer representation of the character in the current > database encoding is exactly that. AFAIK there is no "integer representation" of a character in anything other than Unicode. Unicode is the only case that cannot be handled by a simple encode/decode. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
