TECH Signal 387
Draft proposes functional and type-system improvements for a modern relational query language
↗
Illustration only Photo by Zoshua Colah on Unsplash
A long-standing draft outlines desired changes to relational query languages to address SQL’s perceived shortcomings in syntax, functional programming support, and type systems
SQL’s dominance in relational databases is being challenged by newer query languages that promise better ergonomics and expressiveness. If a modern query language can deliver on these improvements without sacrificing SQL’s declarative power, it could shift how engineers interact with relational data. The proposal highlights pain points that many engineers encounter daily but rarely see addressed in mainstream SQL dialects
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The draft suggests adopting C, Python, or ML-inspired syntax to replace SQL’s PL/I-based grammar
Functional programming features like lazy evaluation and sum types are proposed to reduce mutable state and verbose queries
Improved query planners and user-defined types are called for to make optimization and schema design less opaque
THE READ
What the cluster adds up to.
The draft argues that SQL’s syntax, rooted in 1970s PL/I, feels archaic to modern programmers. While SQL’s declarative nature is powerful, its procedural stored procedures and mutable-state cursors push engineers toward imperative patterns. A modern query language could borrow from functional languages like F# or Elixir to make relational operations more intuitive without losing SQL’s strengths. The proposal does not demand a specific syntax but emphasizes that better parsers and error reporting, like those in Oracle, would reduce debugging friction
Functional programming support is a key focus. SQL’s 4GL qualities already align with lazy evaluation and declarative data description, but most SQL dialects lack a standard library that encourages functional patterns. The draft suggests that a modern language could integrate sum types, discriminated unions, and pattern matching to handle mutually exclusive data more cleanly. This would address common pain points like nullable columns and string-based enums, which often require verbose workarounds in SQL. The challenge lies in maintaining backward compatibility while introducing these features
Query planners and type systems are identified as areas where SQL implementations fall short. MySQL’s cryptic EXPLAIN output is cited as an example of poor optimization feedback, while user-defined types, though part of the SQL spec, are rarely implemented well. Postgres is noted as an exception, with its support for domains and richer type systems. The draft proposes that a modern query language could leverage advances in computer science to make query optimization more transparent and type systems more expressive, reducing the need for manual tuning and schema hacks
The proposal is framed as a discussion starter rather than a finished specification. It draws on real-world experience with MySQL, Db2, and other RDBMSes to highlight gaps that newer query languages like Acadia aim to fill. While the draft does not prescribe a specific solution, it underscores that SQL’s limitations are not inherent to relational data but stem from historical design choices. For engineers, this could mean a future where relational queries are less error-prone and more aligned with modern programming paradigms
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER