go-duckdb

Anyone tried using the Go driver? It has a few open bugs: https://github.com/marcboeker/go-duckdb/issues And a third-party effort, only: https://duckdb.org/docs/api/overview

But also, just to double check, I modified the vendored code and no difference: CGO_LDFLAGS="-L$(pwd)/duckdb/src/include" CGO_CFLAGS="-I$(pwd)/duckdb/src/include" go build -ldflags '-extldflags " -lstdc++ -lm -lduckdb -static"' # github.com/marcboeker/go-duckdb vendor/github.com/marcboeker/go-duckdb/connection.go:4:10: fatal error: duckdb.h: No such file or directory 4 | #include "duckdb.h" | ^~~~~~~~~~ compilation terminated.

I don't have the source code in a good state to publish yet but here's where I'm at. At some point before this CGO_LDFLAGS does work and the header is found (omit the -ldflags args). But when it goes to statically link it can no longer find the header. CGO_LDFLAGS="-L$(pwd)/duckdb/src/include" CGO_CFLAGS="-I$(pwd)/duckdb/src/include" go build -ldflags '-extldflags " -lstdc++ -lm -lduckdb -static"' # github.com/marcboeker/go-duckdb ../../go/pkg/mod/github.com/marcboeker/go-duckdb@v0.0.0-20220427142532-cd9f33e64d9a/connection.go:4:10: fatal error: duckdb.h: No such file or directory 4 | #include <duckdb.h> | ^~~~~~~~~~ compilation terminated. Edit, nevermind about not being in a good state! Here's my code: https://github.com/multiprocessio/duckdb-tests.

I've been beating my head trying to get duckdb to statically link into a Go program (I'm neither an expert with cgo nor ld). If anyone else has been able to do this I'd love to see your build steps. https://github.com/marcboeker/go-duckdb produces a non-static binary by default.

Here is a solved Github Issue related to CGO for the Go bindings! If you have another issue, please feel free to post it on their Github page! https://github.com/marcboeker/go-duckdb/issues/4

Yeah frankly the q benchmark isn't the best even though dsq compares not terribly in it. It isn't well documented and exercises a very limited amount of functionality and isn't very rigorous from what I can see. That said, the caching q does is likely very solid (and not something dsq does). The biggest risk (both in terms of SQL compliance and performance) I think with octosql (and cube2222 is here somewhere to disagree with me if I'm wrong) is that they have their own entire SQL engine whereas textql, q and dsq use SQLite. But q is also in Python whereas textql, octosql, and dsq are in Go. In the next few weeks I'll be posting some benchmarks that I hope are a little fairer (or at least well-documented and reproducible). Though of course it would be appropriate to have independent benchmarks too since I now have a dog in the fight. On a

Generally you would need to write bindings for the system. Experimental DuckDB bindings for Go do exist [1], however, they are rather old and might not work anymore. We also have JDBC support, which might help for languages that know how to use that protocol. ODBC support is not implemented yet, but also planned. We also have a SQLite-compatible C API [2], that can potentially be used to use an existing SQLite driver that uses the SQLite C API. [1] https://github.com/marcboeker/go-duckdb [2] https://github.com/cwida/duckdb/blob/master/tools/sqlite3_ap...

Neither Hannes nor me are very experienced with Go, so we are not the most suitable to do that. We do very much welcome external contributions, and someone did make a WIP go driver [1] in the past. We also have a sqlite3 compatible C API that can be used to use DuckDB. This is actually how we use the sqlite3 shell: we directly use the sqlite shell but bind it to the duckdb library using this API. It might be possible to use the Go SQLite driver in a similar manner to talk to DuckDB. [1] https://github.com/marcboeker/go-duckdb