Not that you haven't had the debate before, but I hope this discussion of my enhancement request for a raw flip() or reverse() function helps to highlight some basic issues relating to Unicode in the database; I don't mean to be beating any dead horses.
Roger Binns wrote: <quote>My point was that your requirements are that, yet someone else wanting a "flip" function could want something different (eg keep combining codepoints together in the correct order). </quote> That others might wish for a Unicode-savvy reverseUnicode() function does not create ambiguity; raw string functions and Unicode-savvy character-functions are wholly different beasts. It's not an either/or choice. You can have both. But should you have both? Does a database need text|character-functions in addition to (one really hopes it's not instead of) raw string functions? Should a database have the intelligence to distinguish between a Unicode base-character and a Unicode combining character? No, because that is simply not part of the database Job Description. The role of a database is to store, retrieve, and serve raw data. *The engine tenders; the client renders.* As there are those who champion the agenda of higher-order Unicode-intelligence in the database, I am championing the agenda that a rich suite of raw (or "naive") string functions remain available in the core. The lack of a raw reverse() function seems an omission that could be remedied without saddling the core with more than a few extra bytes. I do acknowledge that the -Lite in SQLite is very important and I will even take up the "Lite" argument: Unicode-savvy character functions, functions that can distinguish between combining characters and base characters, are much heavier than naive functions. From a Lite-ness angle, the dilemma should not be whether to add a simple lightweight raw string function; rather it should be over whether the database *core* should ever contain functionality to distinguish between base characters and combining characters. Roger Binns also wrote: <quote>In addition the host language you are using (Javascript) is perfectly capable of reversing strings. A simple for loop will do the trick.</quote> From the fact that the client is able to reverse a string it does not necessarily follow that the client is the best place to carry out that function. There are good reasons for carrying out the reversing of strings "raw" inside the database-engine and not at the client, the main one being that engine-side reversal eliminates all possibility of "Unicode intelligence" in the client libraries raising an error should they encounter in the sequence of raw reversed codepoints what would appear to be an "orphaned" combining character. Higher-order Unicode-intelligence belongs in the client, if it belongs anywhere. The naively-reversed string need never find its way to the "Unicode-savvy" client; all operations that make use of the raw string could be carried out by the database engine. Regards Tim Romano _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
