3 ms·

> A bit shameless to ask a question under top HN record, but I always wondered why do not SQL engines give access to their SQL AST to generate queries. A numbe

> A bit shameless to ask a question under top HN record, but I always wondered why do not SQL engines give access to their SQL AST to generate queries. A number of reasons from the PostgreSQL POV (work on it): - our internal parser representation isn't stable and frequently changes from major release to major release, occasionally even in minor releases. - we'd need a lot of additional verbose error checking code to make sure only sensible AST can be submitted - there's two forms of parser AST "raw" and "analyzed". The former is produced without access to the database, the latter has done validity checks, type lookups, etc. The former is what you could validly produce remotely - but it's also more cumbersome to deal with. I think there's arguments for supporting a useful different representation than SQL, but I think doing this with the already existing AST isn't going to fly. And a new proper language / representation would be a lot of work... Edit: formatting

naasking 9y ago
> And a new proper language / representation would be a lot of work... I don't think a new language would be needed, and most of the work has already been done in projects like LINQ. You'd just need to expose a stable AST front-end, which would be a lot easier than a whole new parser. I mean, it's just relational algebra right? ;-)
- 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.

naasking 9y ago

> And a new proper language / representation would be a lot of work... I don't think a new language would be needed, and most of the work has already been done in projects like LINQ. You'd just need to expose a stable AST front-end, which would be a lot easier than a whole new parser. I mean, it's just relational algebra right? ;-)

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.