V2 General Discussion

[taniabogatsch]

Currently, go-duckdb tries to avoid any breaking changes. However, in a recent discussion about opt-in vs. opt-out here for additional driver features, we concluded that some breaking changes when moving to a new version are beneficial.

I am opening this discussion to address possible changes and improvements relevant for a V2.

Related discussion addressing static library builds: #349

[marcboeker]

For v2 we should also think about the pre-built libraries as they are getting larger and larger over time. On the other hand, building DuckDB on the fly takes some time and a proper build chain. An fetching pre-built libraries from a different source is not Go-like.

[dxh9845]

I have been using this library for work. In general, I think the library works decently well, but I do think the following improvements would help ergonomics:

• Refactor Apache Arrow dependency to be opt in. It could possibly be a separate go module, or enabled explicitly with build tags. I think Golang Migrate does a good model of how this could work possibly?
• Improve the documentation around Appender. Currently the appender is pretty confusing to use - the docs mention you should use .Close, but it seems like .Flush is also required to make things work? I could be wrong.
• More examples within the Go Doc. Right now the examples are spare and usage can really only be figured out via using the library and seeing what works / what doesn't.

Pipe dream, but probably not possible:

• Remove the C bindings and make this library native Go. I don't think this is realistic, but ideally users could use this library without CGO and could build statically compiled binaries.

[james-lawrence]

I suspect removing cgo is possible via wasi but its a very large lift; but it would resolve the multiple platform binary build problem. there is a sqlite3 library that did this.