So the "A" in "A ess-queue-ell" engine felt like it should have been an "An" until I realized it was meant to be pronounced like "sequel"
Have you ever considered pronouncing it as squirrel by the way?
Now I usually say sequel because everyone else does. That and it rolls off the tongue better than S-Q-L.
The IR I've used is the Calcite implementation, this looks very concept adjacent enough that it makes sense on the first read.
> tmp2/test-branch> explain plan select count() from xy join uv on x = u;
One of the helpful things we did was to build a graphviz dot export for the explains plans, which saved us days and years of work when trying to explain an optimization problem between the physical and logical layers.
My version would end up displayed as SVG like this
https://web.archive.org/web/20190724161156/http://people.apa...
But the calcite logical plans also have that dot export modes.
It's a method from "RuleMatchVisualizer":
https://github.com/apache/calcite/blob/36f6dddd894b8b79edeb5...
Here's a screenshot of what the webpage looks like, for anyone curious:
https://github.com/GavinRay97/GraphQLCalcite/blob/92b18a850d...
In a larger system we are building we need a text-to-sql capability for some structured data retrieval.
Is there a way one could utilize this library (sqlglot) to build a multi-dialect sql generator -- that is not currently solved by directly relying on a LLM that is better at code generation in general?
For example, on the JVM there is jOOQ, which allows you to write something like:
select(field("foo"), avg("bar")).from(table("todos"))
Alternatively, you can ask an LLM to generate a specific dialect of SQL, and then use jOOQ to parse it to an AST, and then render it as a different dialect, like:
val parser= DSL.using(SQLDialect.POSTGRES).parser()
val parsedQuery = parser.parseQuery(postgresQuery)
val renderedMySQL = DSL.using(SQLDialect.MYSQL).renderInlined(parsedQuery)
println(renderedMySQL)
GMS lets you provide your own table and database implementations, so we use GMS to perform SQL queries against Grafana's dataframes - so users can join or manipulate different data source queires, but we don't have to insert the data into SQL to do this thanks to GMS.
we’ve been through all of that at wobby.ai we ended up building a system where the data team defines guardrails and reusable query templates, so the agent doesn’t just make stuff up. it can still handle user prompts, but within a safe structure. if you want to save yourself from debugging this stuff endlessly, might be worth checking out wobby.ai.
jimbokun•1y ago