которого и является финишным IR. Why not?
Хорошо. А план в реляционных операторах содержит детали выполнения, вроде того какой именно алгоритм соединения таблиц используется?
имею в виду, конечно, разработку своего SQL движка, а не смысл вообще делать SQL движки)
Я в хазелькасте работаю, у нас есть и imdg (распределенный кэш), и движок потоковой обработки. Приложения можно делать на разных языках под разные задачи, но “забор” данных проще всего всем делать на SQL.
Риторический вопрос: зачем нужен громоздкий и некомпозируемый SQL, который потом все равно внутри транслируется в красивую и компактную реляционную алгебру?) Почему бы сразу запросы не писать в синтаксисе рел.алгебры?
Пока нельзя вкладывать таблицы в таблицы (нет отношений между отношениями) HOL действительно без надобности. А вот логика второго порядка — в самый раз, можно писать запросы, работающие с любой подходящей таблицей, а не только явно заданными. 😉
Решается неявным учётом id (как и в случае с мультимножествами, кстати).
Это ж костыль! Зачем какие-то полумеры?! 😂
union(tbl, tbl) и иды не помогут.
Это не костыль, а чисто синтаксическое решение, подобно DCG и DCTG в Prolog.
или ещё лучше на языке теории acsets: https://arxiv.org/abs/2106.04703
А какой там внутренний язык категории? 😁
оно образует слайс-категорию, так что какая-то разновидность завтипов
Обсуждают сегодня