Proposal : make a v2 to be more friendly with golang developper

[blackrez]

Hello guys,

I found the chdb-go quite messy (but I know it's not easy to write a wrapper like this) and hard to modify.
Also there is an dependancies on arrow (it use cgo and sometimes I don't want ) and parquet-go, that I don't need since clickhouse know how to read and write parquet files.

That why I started a new binding for experiments with purego.

https://github.com/blackrez/chdb-purego

My objective was to start from 0 and try some ideas (the first one was to use purego).

But chdb-go is the official binding and maybe it's better to share the ressources.

I have some ideas about the v2 :

• be cgo free (using purego)
• have easy way to install and manage libchdb (download ? use embed ?)
• use https://github.com/ClickHouse/ch-go/tree/main/proto for a better data exchange between go and chdb
• make arrow support optional
• offer a low level API
• offer a sql interface (it is already the case with the actual version)

What do you think ?

NB : I know for the first one, there is a PR but the idea it to start from zero and make chdb-go more go friendly.

[auxten]

I think it could be a good idea to use ch-go code to exchange between go and chdb.
It will need further benchmark to find out if arrow or parquet is faster than ch-go impl.
What's your idea? @agoncear-mwb

[agoncear-mwb]

Yes, we can implement ch-go for data interchange, but i guess it's something we can think of after we manage to implement the v3 and have a "stable" working version. include a new format and / or remove the existing ones in this big change from cGo to pureGo, could be cumbersome in my opinion

[agoncear-mwb]

@blackrez the cgo free version is ready, and we also removed arrow dependency for the moment and leaved only parquet as a default parser.
We can start to think about using ch-go for reading/writing native format, but it will be hard to use since the library itself is created upon a tcp connection, not an embedded system.