OK, I'm fully with you (for now). I'm talking about the case the constraint is specified as part of a column definition. And yes, I understand that **execution-wise** it makes no difference, as it clearly says [here](https://sqlite.org/lang_createtable.html#ckconst): >A CHECK constraint may be attached to a column definition or specified as a table constraint. **In practice it makes no difference.** Following the syntax diagram the compiler has the (now missed) opportunity to know if the constraint was part of a column definition or table definition. It can, therefore, tag this constraint with a name, either the column's, or no name (blank) if it is at the table level. Then, it can use this name to produce more informative errors when that particular constraint fails. Of course, **if and only if** the compiler is smart enough to optimize to a single execution path separately defined but identical operation constraints -- same exact instructions -- (which would be odd to happen in practice as you normally `CHECK` the column you're on when doing it at the column definition, so at least the operand(s) could change), then what I propose would be impossible, obviously. But a workaround would be for the tag to include all names like: `col_a, col_b`. Still, better that no help at all. Otherwise, it doesn't seem that much of a chore.