Why are unquoted identifiers upper-cased per SQL-92?

Section 5.6 of the SQL-92 standard contains rules 10...13 per which unquoted identifiers should be upper-cased, so foo becomes FOO but "foo" remains foo.

These rules are respected by Oracle, IBM DB2, Snowflake, and ksqlDB but not by Postgres, MySQL or SQLite, for example.

The question is, why? In my understanding, the optional quoting of identifiers in a language with a lot of keywords makes sense. Consistent case sensitivity or insensitivity of identifiers would also make sense. But making it dependent on the identifier being quoted doesn't look rational.

What am I missing?

But making it dependent on the identifier being quoted doesn't look rational

Case-sensitive identifiers suck. Imagine the chaos of having tables named Foo, FOO, and foo, and all the frustrating erros of users who write SQL queries and get the case of objects wrong. But some older RDBMS system were inherently case-sensitive (Oracle I'm looking at you).

So transforming identifiers to all caps is an old-fashioned workaround to not having the ability to support a case-insensitive catalog.

So create table Foo ... actually creates a table named "FOO" and in a SQL Query select * from foo the object name is uppercased before searching for it in the catalog.

But having support for mixed case identifiers is an important feature. So if regular identifiers are implicitly converted to all caps, it makes some sense to allow mixed case identifiers if explicitly delimited with ".

For instance SQL Server has mixed case identifiers, and an application might rely on reading the mixed case identifiers from the catalog. This is possible in Oracle by creating the table with mixed case quoted identifiers.

Also this describes the actual behavior of Oracle, which was one of the only RDBMS systems around back then. So it also may be that the the Oracle design is being codified by the SQL standard.

StackExchange Database Administrators Q#321413, answer score: 8