Roger,
>You are aware that "standard" SQLite is used in devices with a few >kilobytes of memory through workstations and servers with gigabytes of it! That's precisely why such approach is interesting! >As far as I can tell you want some extra "standard" collation sequences >and propose shortcuts that will get them mostly right. And you want >someone else to write the code! Phew! It wasn't not my intention to see anyone here go ballistic reading my post. But look: 1) I never pretended at any "standard", just a useful set of features 2) what I said is that it can be made to fit _most_ needs with little requirements in memory and cycles 3) I offered (twice) to pay a reasonable fee for such development if it implies some branching from mainstream core. The support page indeed reads: If you would like professional support for SQLite or if you want custom modifications performed by the original author or SQLite, these services are available for a modest fee. For additional information visit <http://www.hwaci.com/sw/sqlite/prosupport.html>http://www.hwaci.com/sw/sqlite/prosupport.html or contact: D. Richard Hipp Hwaci - Applied Software Research 704.948.4565 <mailto:d...@hwaci.com>d...@hwaci.com I don't make this up you know. >SQLite makes it very easy to have extensions and to register them. For >example see ><http://sqlite.org/c3ref/auto_extension.html>http://sqlite.org/c3ref/auto_extension.html True, but I think that no extension will ever overload consistanly the macros (!) and other deep code (like inside FTS3) involved in REGEX, ORDER, GLOB/LIKE, UPPER... Or maybe I overlook something obvious. OTOH, having collation and comparison located in _code_ makes them difficult to port. >Generally the best approach would be to produce the code as an >extension, document and test it well and then add to the contributions >page at <http://sqlite.org/contrib>http://sqlite.org/contrib - once >enough developers have used it >and vouched for its utility then it would be far easier to lobby for >incorporation into the "standard" SQLite. I'm not lobbying, nor asking for good practice guidance. I was asking the group their opinion about the usefulness of such feature. As far as I can see, it would require to be part of the core to deliver full power. I understand how difficult it is for some english-only developpers or users, having to support code for non-english speakers / writers. I just thought it was fading now. >For you to convince me of the utility of the code, you'd need to list >which locales it gets right and which it gets wrong. Software can seem >pretty dumb to users almost getting some things right. Please make me the favor to _read_ my post. I believe you have enough experience to understand it and think about the _practical_ usefulness of such behavior. It doesn't work with "locales" at all. It allows the user to declare its own set of characters and the way SQLite should handle them for low-level operations. It's a DIY thing! BTW locales are far from perfection. For instance: you have to search text, say an address book in a cellphone, with FTS3 and you know the base may have words or names in a dozen european languages. How would you do? ICU? Huge and slow, but even then: which "locale" would you use? I'm in no way saying that ICU is a bad thing. Of course it's been extremely carefully coded and reviewed. It's a very nice building block ... but only for those that need the most comprehensive solution available (and can afford to bring it aboard). Perhaps the best way is practice: what's the way to find this guy named Éric or is it éric, or Eric, or eric? He lives in MÜNCHEN, München, MUNCHEN, Munchen or ... Munich. To answer another post by Ian, yes I've had a look at ICU. Of course ICU knows about its size, but what can they do about it, since their goal is to implement the most complete support possible? And again, that's a very good thing. But my reluctance is elsewhere: I do not adhere that much in locales. I use more than a strictly defined locale "locale" and less than a world locale! Also, yes I write most users. BTW SQLite would possibly have more "rest-of-the-world" fans if a more simple handling of diacritics were available! Look: we in Western Europe have been computerized in ALL PURE ASCII CAPITALS for many years. Then in mixed casing, but always ASCII. Now is perhaps the time for something else. Jean-Christophe _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users