prql
prql copied to clipboard
PRQL
Go bindings
Are there any plans, or has anyone started, bindings for Go?
If not, I might be able to start that up. I use PostgreSQL on a daily basis in Go and this seems to be a much easier to read and maintain version of querying that I would love to integrate into my projects.
I figure maybe cross-compiling the Rust => C => Go (C Binding) maybe? Otherwise another (lean) implementation of the compiler to get a library working might be in order. In that case, would love to see struct methods that reflect the API for building queries in a method-chaining sort of style.
I would very much like to see C/C++ bindings and would like to use PRQL as a frontend for the SQLite backend in lnav. Is this something to be done with cbindgen? (I'm not too familiar with how folks use Rust libraries in C programs) I would be okay with the current minimal interface of passing JSON strings back and forth, but don't want to shell-out to prql-compiler.
It looks like the compiler already provides some pretty clear errors for PRQL issues. I'm hoping there will be enough information in the AST so that semantic errors reported by the underlying DB can be reported back clearly (e.g. give the line number in PRQL of the table reference that is bad). If the PRQL compiler could also report expected values for missing inputs, that would help with doing TAB-completion (e.g. from wants a table name).
I'm not too familiar with Rust, so can't help with cross-compiling of any sorts. For Go at least, I've started a repo where I'm just going to re-implement the language. So if anyone is curious on following that it'll at: go-prql
When I get something working I'll come back to this and we can publish it as a suggested binding/implementation/library.
I wasn't familiar with go <> rust bindings. It looks possible, though not trivial
- https://github.com/BurntSushi/rure-go is regex in
go - here's another effort: https://spectralops.io/blog/rust-vs-go-why-not-use-both/
One advantage is that we only have a couple of methods — prql_compiler::compile / prql_compiler::to_json for the serialized object.
@chris-pikul — that's very welcome, and we're very happy to support you. We have lots of tests that might be helpful — PRQL is extensively tested, and some of the them are in their own .prql & .snap files, so easy to share.
That said, there was an effort to build the language in python, which was very productive initially but, as the language grew, became more difficult to keep up to speed. Eventually @charlie-sanders swapped out the backend of the python implementation for python bindings in the form of prql-python.
But maybe there are ways of making a better implementation than our rust version with go, which we'd ofc welcome!
@max-sixty The tests will be most welcome, especially language tests. I'd say my inspiration and target is not to replace the PRQL Rust compiler, but to add an alternative. Go allows me some flexibility that I'm not sure I could get with Rust. So as much as the Rust version can be the baseline and slightly more performant option, a native Go version would just work better for Go projects (as expected).
One of the issues AFAIK with doing a Rust->C->Go binding is that Go basically doesn't really like C bindings because of pointer/memory safety so it becomes a bit tricky. So my plans for the Go version is:
- Complete Parser/AST compiler for PRQL strings (code).
- SQL generation from AST.
- Method-chaining query builder to help create PRQL queries as an API option.
- Go based CLI binary to ease testing and as an alternative CLI package.
- Additional extension package
go-prql-plusthat can be a drop-in library for Go projects providing not only the PRQL language, but DB connection functionality for executing queries, transactions, pooling, etc. (this is far future).
And as a final note, when I get the Go version down, and a better understanding of the parser requirements I might tackle the Node.JS/Deno/TypeScript version after that. Basically because the WASM version is great, but query execution typically happens on the back-end, so a server oriented JS library for Node/Deno seems more beneficial for adoption.