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:[email protected]>[email protected]
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
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
