We used to simply forward all FTS match string interpretation to SQLite's FTS implementation, and used to allow and announce its features, e.g. use of AND/OR keywords for more complex matches.
When FTS5 came through, the FTS query syntax got a major revamp, also in the complexity of the allowed syntax, including non natural language (e.g. symbols like ^ or *).
This makes all the gory details of this parser available to users, but also its pitfalls, e.g. execution-time errors are raised when the search string contains special symbols non-interpretable by the FTS5 parser.
Since fts:match is often plugged directly to search entries in UIs around, it seems a bad approach to maybe fail the query or not depending on the last character entered. Arguably applications might cater for this additional level of syntax, but it's sadly not trivial and kind of a moving target (fts5 still does add features from time to time), seems bad to leave this up to applications.
So, hide all FTS5 syntax from the upper layers. The fts:match string forcibly becomes '"%s"' so it is ensured that all the input string is interpreted as "search terms". It is also ensured that the given search string cannot break out of that. The '' character makes the last term in the search string be interpreted as a prefix search.
We lose some neat things there, like AND/OR mentioned above, or the possibility to match a single property instead of a whole row. AND is already the default, OR can be obtained through additional fts:match, and the last one is a rather obscure feature. Might be neat to bring back in another form someday. (e.g. make fts:match a FILTER function).
Fixes: gtk#3114 (closed)