> ... there's a bug ... where its quite plainly syntactically incorrect It's not a bug. The behavior is plainly and clearly documented at the doc pages I linked above to help you understand that the behavior conforms. In particular, the last syntax chart I linked shows that your odd spelling of a typename should be expected to be accepted by the parser, and the type affinity determination rules (linked earlier) reveal that it should survive semantic processing also. > SQLIte is flexible but shouldnt there be SOME kind of error when there a pretty obvious syntactical issue like this ? What is pretty obvious to you is not as simple as you imagine. The typename acceptance laxity is a convenience for those migrating SQL constructs from N<sup>a</sup> other DBMSs to SQLite. Across that set of other DBMSs, a wide and fluctuating variety of typenames are legal. I would grant that, as wetware operators, we humans can generally recognize the trying-to-be-a-typename subset of names, but it is unreasonable to expect SQLite to do that. It would be a maintenance headache, and a death-by-dribbles ongoing "bug" source. In several weeks, the STRICT option will be available. The set of accepted typenames for tables with that option is very small (as another link I provided above shows.) So you should use that if it is too hard to remember to separate your column definitions as SQL requires. ---- a. N is an unknown and unbounded number.