> I see what you're saying. To me, this seems to be a non-issue. I was disagreeing with your contradiction of Jay. I think lack of assured predictability (or possible "instability") is part of why '*' as a columns specifier is disfavored. > Because it's just as consequential as using *. If one is allowed, why not the other? I sort of buy into that argument and would not be aghast if somebody were to talk the SQL evolution committee into adopting it. > Internal changes in the DBMS may also return a different order with *, right? Yes, in general. Not likely, though. It is the chosen names that may change. For example, consider a UNION query. It is allowed to have differing column names for its component selects. Which component select's names should win? > ... if one (*) is affected and it's acceptable, why would it be a problem with the other? (Taking "the other" to be * with some named columns omitted:) It's not SQL, and it's yet another feature tending to take the 'Lite' out of SQLite. The SQLite library is intended for use in applications, including quite resource limited one. The convenience of those who type at the CLI shell is low on the priority list for library features.