On Fri, Nov 05, 2004 at 01:50:34PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
It doesn't check the validity of encoding nor makes any conversions internally.
Afaics it does, both when necessary in the communication with clients, and when collation etc calls for it.
Documentation clearly says it doesn't - I posted a quote before.
You seem to ignore that as the discussion has progressed, noone has opposed adding a flag to turn it off. Isn't that enough for you?
It is enough for me, but if noone opposed why it is still continues? :)
Valid point, although it still would be nice to see the kind of overhead the extra overhead incur.
Why? Is mere fact that I (or anyone else) don't want _any_ (no matter how small) overhead not enough? :)
and utterly oppose. How do you know if the string is to be UTF8/16 decoded when you get it back?
How do you know that string you wrote to file is valid UTF-8 when read back? How do you know what kind of data is stored in file or any other external source if you didn write it?
happen to not be invalid UTF-8. What if you want to use the sqlite collation functions etc on those strings? They sure as hell won't work correctly on unencoded eight bit chars.
There is extermely nice feature in sqlite - I can define my own functions and collation sequences :)
Regards, /Al