4 ms·
> You'd just need to expose a stable AST front-end, which would be a lot easier than a whole new parser. "Just". You still need a parser for that AST if it co
by anarazel 9y ago
> You'd just need to expose a stable AST front-end, which would be a lot easier than a whole new parser.
"Just". You still need a parser for that AST if it comes from the client, you need to convert that into the actual internal representation with validation and everything.
> I mean, it's just relational algebra right? ;-)
It's really not. A lot of SQL can't conveniently expressed in relational algebra (could luck with recursive CTEs) and a lot of other queries aren't as efficiently representable.
- naasking 9y ago> "Just". You still need a parser for that AST if it comes from the client, you need to convert that into the actual internal representation with validation and everything. Yes, just: http://lambda-the-ultimate.org/node/5375 http://lambda-the-ultimate.org/node/5375 > A lot of SQL can't conveniently expressed in relational algebra (could luck with recursive CTEs) and a lot of other queries aren't as efficiently representable. Clearly some language is being used to reason about these things, and evidently, this language is reflected in some SQL-like surface syntax. It would be no more a burden to provide an extensible AST than an extensible SQL-like language. In fact, it'd be considerably simpler since tokenizing, parsing and verification would all be simpler.