As explained [here for check constraints](https://sqlite.org/lang_createtable.html#ckconst), the expression is less limited than you have led yourself to believe. If you follow the non-terminal, "expr", in that railroad chart, you will see that an arbitrarily complex expression can be written in its place among the more confined syntax elements. At that link on check constraints, you can learn that a "CHECK constraint may be attached to a column definition or specified as a table constraint. In practice it makes no difference." This further supports what the fully expanded syntax diagram says. My contention is that helping with the diagnosis of those arbitrarily complex expressions, just when they fail, would be much more costly than it's worth. And, as I [explained in this post](https://sqlite.org/forum/forumpost/3ad538a776?t=h), such a check performed when a table is created or altered could even fail when such a result would work against the SQL writer's legitimate intention. (Consider, for example, using the current datetime as a default value where the check insists that it fall within business hours but schema changes are done safely outside of business hours.)