A design proposal for SQLite version 3.0 can be found at:
http://www.sqlite.org/prop2.html
Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows:
* Support for UTF-16
well, the question is: Support UTF-16 to what extent? I think here of sorting questions, (but other may arise). Obviously, sorting within a single language is specific to that language, whereas sorting a, say, german word with an ukrainian word is what a programmer calls "undefined". And comparing two german words - according to the rules a german user would expect - might be different from what a default comparison routine would return.
With such support the locale would become a property of a text column. And if some application puts data into that column which has no valid representation in that language, than of course locale-specific comparison would fail and some memcmp()-like comparison would kick in.
Without such facility UTF-8/16 support would remain not much more than another way to import BLOBs, with a somewhat better support for matching an entry.
Of course, I understand that DRH (or whoever will be in charge for that specific task) would not want to collect all those stuff himself. Maybe we - the community - could provide DRH with a library of comparison functions each implementing a single locale.
just my 2 cents, /eno
--
"Home is where you hang your @"
gpg --fingerprint [EMAIL PROTECTED]
3AA2 3E2C EBE5 9ACE AA01 F207 1789 4D51 D085 AF45--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
