"The lower(X) function returns a copy of string X with all ASCII characters converted to lower case. The default built-in lower() function works for ASCII characters only. To do case conversions on non-ASCII characters, load the ICU extension."
FAQ item (18) Case-insensitive matching of Unicode characters does not work, at https://sqlite.org/faq.html :
"The default configuration of SQLite only supports case-insensitive comparisons of ASCII characters. The reason for this is that doing full Unicode case-insensitive comparisons and case conversions requires tables and logic that would nearly double the size of the SQLite library. The SQLite developers reason that any application that needs full Unicode case support probably already has the necessary tables and functions and so SQLite should not take up space to duplicate this ability.
"Instead of providing full Unicode case support by default, SQLite provides the ability to link against external Unicode comparison and conversion routines. The application can overload the built-in NOCASE collating sequence (using sqlite3_create_collation()) and the built-in like(), upper(), and lower() functions (using sqlite3_create_function()). The SQLite source code includes an "ICU" extension that does these overloads. Or, developers can write their own overloads based on their own Unicode-aware comparison routines already contained within their project."
All these are cope-outs. None of the stated reasons make much sense to me.
If I am distributing an app that uses the installed SQLite, you expect me to build a special version of SQLite and bundle it with my app?? Or require some weird extensions?
That is, do you compile and distribute the version from sqlite.org or do you depend on someone else to package it for you?
If the former, then change the compile flags.
If the latter, isn't the problem that your distro/packaging provider didn't enable the flags you wanted? Complain to them.
As a quick look, I see https://github.com/karlb/sqlite-icu claims "includes a loadable icu extension module for sqlite. This allows other python packages to use this extension without requiring dependencies outside of the python ecosystem". I've never tried it.
Then they should look at my foldcase and lower case table generator at https://github.com/rurban/Unicode-Towctrans/
3336 bytes for the case tables are not comparable to the ICU mess, and easily shippable.
https://sqlite.org/lang_corefunc.html#lower
"The lower(X) function returns a copy of string X with all ASCII characters converted to lower case. The default built-in lower() function works for ASCII characters only. To do case conversions on non-ASCII characters, load the ICU extension."
FAQ item (18) Case-insensitive matching of Unicode characters does not work, at https://sqlite.org/faq.html :
"The default configuration of SQLite only supports case-insensitive comparisons of ASCII characters. The reason for this is that doing full Unicode case-insensitive comparisons and case conversions requires tables and logic that would nearly double the size of the SQLite library. The SQLite developers reason that any application that needs full Unicode case support probably already has the necessary tables and functions and so SQLite should not take up space to duplicate this ability.
"Instead of providing full Unicode case support by default, SQLite provides the ability to link against external Unicode comparison and conversion routines. The application can overload the built-in NOCASE collating sequence (using sqlite3_create_collation()) and the built-in like(), upper(), and lower() functions (using sqlite3_create_function()). The SQLite source code includes an "ICU" extension that does these overloads. Or, developers can write their own overloads based on their own Unicode-aware comparison routines already contained within their project."
All these are cope-outs. None of the stated reasons make much sense to me.
If I am distributing an app that uses the installed SQLite, you expect me to build a special version of SQLite and bundle it with my app?? Or require some weird extensions?
Unicode is about 300,000 characters at most.
How are you distributing SQLite now?
That is, do you compile and distribute the version from sqlite.org or do you depend on someone else to package it for you?
If the former, then change the compile flags.
If the latter, isn't the problem that your distro/packaging provider didn't enable the flags you wanted? Complain to them.
As a quick look, I see https://github.com/karlb/sqlite-icu claims "includes a loadable icu extension module for sqlite. This allows other python packages to use this extension without requiring dependencies outside of the python ecosystem". I've never tried it.
There are also alternate sqlite bindings for Python, like https://github.com/coleifer/cysqlite .