Maybe allowing bare words as both identifiers and keywords that could occur in the same position was never the right solution. SQL's roots start young in programming language design so no shame on anybody for not knowing. But e.g. if you're developing an ORM today that generates SQL strings and that SQL dialect might change in a DB upgrade later you should just be always quoting user identifiers.
Is there any programming language which doesn't have this property? All of the mainstream ones certainly use bare words as both keywords and identifiers, and there can sometimes be ambiguity. Most don't even have a solution like quoted identifiers (though quite a few do).
I'll admit that I'm not an expert here but to my eye it's a combination of bare words and cases where the position might be amgiuous, combined with the range of dialects where your reserved words could even change in the future. `select distinct` could be `select [distinct]` or just `select distinct`. Compare to say C where `sometype somebareword` isn't ambiguous because `sometype` is always a language keyword. But wait you say, with typedefs sometype could well be a `typedef stuct somebareword! Yep, it's a problem here too and I've been lying all along.
So that's some rambling but I think you're right, it's just a problem in SQL because of the range of dialects and the fact that they can change out from under you.
Or, for Common Lisp at least, perhaps we can say that (,), #, ;, ", `,', :, commas, whitespace, and numbers are actually the keywords, since most other ASCII chars are valid identifiers but these aren't (so you can have a variable named = or ?, but you can't have a variable named # or 1. And in that case, CL also mixes up "keywords" and identifiers just like everyone else :) .
> Compare to say C where `sometype somebareword` isn't ambiguous because `sometype` is always a language keyword. But wait you say, with typedefs sometype could well be a `typedef stuct somebareword! Yep, it's a problem here too and I've been lying all along.
Even without typedefs, you have a problem more closely related to "select x" VS "select distinct x" - you can have "long x;" or "long double x;".
Either way, yes, I think we agree - there's a difference in quantity and stability of keywords with SQL, but not much else.
