On Thu, Jun 04, 2015 at 11:45:28AM -0700, Darko Volaric wrote: > Which sort of leads me to my next feature, which is bypassing the SQL > language. [...]
I like SQL, but sure, if the compiler worked by first parsing into an AST, and if the AST were enough of an interface (versioned, though not necessarily backward-compatible between versions), then one could: - write different front-end languages (though an AST isn't needed for this: you can always generate SQL) - write powerful macro languages - write alternative/additional optimizers (and linters, syntax highlighters, ...) that work at the AST level If the VDBE bytecode were also a versioned interface then one could write peep-hole optimizers as well. One might even want to generate IR code for LLVM, or use a JIT-er, though for SQL I don't think that would pay off. I suspect that most of the CPU cycles go to data-intensive tasks such as I/O, cache thrashing, and encoding/decoding. I'd be much more interested in SQLite4 being finished than an LLVM backend for SQLite3, and I'd be very interested in seeing if word-optimized variable-length encoding would have better performance than byte-optimized variable-length encoding. The point though is that using an AST would make the system more modular. > [...]. Why use that crusty old syntax when it's equally expressible in > JSON, XML or something else. Again I see it just as an API, [...] Now I'm confused. JSON and XML are not query languages. There exist query languages for them (e.g., XPath/XSLT for XML). I suppose you might have meant that SQL itself is a data representation language like JSON and XML are, and it is (data being expressed as INSERT .. VALUES ..; statements). Nico --
