I’d like to point out that sum types would be great.
(Sum types let you have any of two or more different types in one value)
For example, I could work around the issues with NULL by defining an enumeration type with values like MISSING, UNKNOWN, INVALID, … and then I can have a column that is a sum of that type with the type we normally keep in the column.
We would need some machinery to declare how aggregates work, but I think that’s very much in the spirit of how types work in Postgres now.
In general, I would think we could make SQL a better functional programming language by just implementing good fp features like this.
On Feb 10, 2022, 11:09 -0800, Merlin Moncure <mmoncure@gmail.com>, wrote:
- Also nested function definitions, so top-level functions can be built out of local auxiliary functions.
- Other languages
- Tutorial D, Datalog, Quell, let’s open this puppy up!
- SQL is a terrible, no good, very bad language
Postgres used to suport QUEL way back in the day. Being blunt, there is zero chance of this happening in core. A query language translator out of core, preprocessing the language into SQL, might work. SQL has evolved far beyond what those languages could practically offer. Main benefit here would be to better support relational division, which bizarrely has yet to arrive in SQL.
A portable, low-level API
FYI, there was a semi-serious commercial attempt to do this back in 2001, Dataphor. It's been opensourced. Wikipedia has a pretty good write up on it:
IMNSHO suggestions like these should travel this technical path; take the data language you want and translate it into SQL. Some of these translations will end up being complicated (read: slow). Iterating this kind of thing outside of core would allow for faster development.
merlin
