Use case

Compatibility with legacy tools and users.

Describe the solution you'd like

A group of settings enable_case_insensitive_columns, enable_case_insensitive_tables, enable_case_insensitive_databases.
It is better to have separate settings, because we may want to enable something else in future (e.g. functions).

We will maintain a map from lowercased name.

The name will be found only if:

• there is no exact match;
• the match for lowercased name is not ambiguous.

If the match is ambiguous, the error message should clearly indicate it and list all the options.
We can try to find lowercased name even if the corresponding setting is not enabled - only to provide better error message about the possible match.

It is enough to support ASCII only, because full Unicode support will require locales:
https://languagelog.ldc.upenn.edu/nll/?p=73

We can restrict case insensitive matching only if the identifier is not quoted.

Describe alternatives you've considered

1. Not doing that.
2. We can also implement per-table and per-database option for case insensitivity, for example - for INFORMATION_SCHEMA.

Additional context

https://news.ycombinator.com/item?id=30040104

We also should admit that case sensitiveness (what ClickHouse is doing) is undoubtedly better.

Please put 👀 reaction if you don't want this feature to be implemented.