As stated in the [documentation](https://www.sqlite.org/optoverview.html#the_like_optimization), the LIKE operator will only use an index if the right hand side is a string literal or a parameter bound to a string literal (among a few other conditions). Why is an expression yielding a constant string not acceptable? Specifically, I have tried this:
```
CREATE TABLE t1 (
id INTEGER NOT NULL PRIMARY KEY,
name TEXT NOT NULL,
name_simple TEXT NOT NULL AS (UPPER(name)) STORED
);
CREATE INDEX t1_name_simple ON t1(name_simple);
PRAGMA case_sensitive_like = on;
EXPLAIN QUERY PLAN SELECT *
FROM t1
WHERE name_simple LIKE 'A%';
EXPLAIN QUERY PLAN SELECT *
FROM t1
WHERE name_simple LIKE UPPER('a%');
```
Output:
```
QUERY PLAN
`--SEARCH t1 USING INDEX t1_b (name_simple>? AND name_simple<?)
QUERY PLAN
`--SCAN t1
```
The first SELECT uses the index, while the second doesn't. How about allowing this kind of RHS? When using EXPLAIN, I see that a "Once" opcode skips over the UPPER() invocation on all but the first iteration, so it seems to be known to the query planner that this is a constant.
When ICU is used, the like() operator is overloaded and then the LIKE optimization is also disabled. I plan to implement a function in place of UPPER that converts strings (persons' names) into plain uppercase ASCII, thereby allowing efficient searching. Of course I could first apply that function from C before binding the parameter, but I'd rather keep the logic in the SQL statement. Thanks for your opinions.