Comment by setr

Afaict, the state of SQL as a grammar with tooling is kind of pathetic.

As a standardized language, it doesn’t really exist; everyone implements numerous extensions, and almost no one is fully ansi compliant

Almost all formatters attempt to be generic (believing standardization exists), and fail to support the full grammar for any dialect.

Across the board, all parsers have pathetic error message support (error on line 3, which is actually just the start of the statement).

The schema offers type constraints, but querying/ide’s extract no value from that (that is, types are statically specified/constrained, but query editors all pretend its fully dynamic)

Theres a lot of awkward nonsense, like where clauses are parsed before the select in most parsing engines, causing alias usage to fail without wrapping in a subselect/with clause

The grammars themselves are an inconsistent, ad-hoc mess

The grammar is also unnecessarily context-dependent (eg from must follow select, and where after that), making programmatic composition unnecessarily difficult

I don’t know how much of the tooling issue is a result of SQL as a language versus the history itself, but I can at least confirm that trying to parse multiple dialects is absolute hell, which would at least explain the sorry state of affairs for eg formatters.

But the majority of its expressive power derives from the relational algebra, and has nothing to do with the SQL grammar, and thats the majority of its value. It seems obvious to me that at the very least the compositional issue of SQL, and its self-inconsistent grammar, should be vulnerable to near-lossless improvement without too much struggle, though I can’t say what the alternative would actually look like.

But it seems like its riddled with a lot of unnecessary flaws