feat: sql to substrait #80
Conversation
There was a problem hiding this comment.
One future improvement might be to use the dialect to handle conversion from the local name into Substrait. That could get the right implementation and/or option converted without needing to assume that the name matches somewhere. Obviously that would need a dialect file for each engine which we don't have yet.
There was a problem hiding this comment.
since there is now a growing number of dependencies used in tests, I think we need to pin dependencies to specific versions to ensure repeatable test runs both locally and in ci. I plan to switch gh actions to use uv for tests in a follow-up PR.
|
For now we'll probably have to start with some sort of base dialect class that can be extended by dialect implementations to better make sense of what will actually be required from the eventual dialect files. function name mapping is an obvious one of course, but I feel like there might be other requirements. |
Adds basic support for turning sql strings into substrait plans.
Covers most common sql operators, but function support is minimal.