Usability improvement for selects with ch-go

[nikita-vanyasin]

Hello!

some time ago, I've switched one of my applications from clickhouse-go to ch-go.
It turned out, writing the code for select queries is not quite easy, especially I was not able to find a good example of handling such query.

After some experiments I came up with working code, but it was not quite readable and human-friendly.

So I've created a small helper library to make the process a bit more fancy while not losing performance.

Please take a look:

• Blog post with motivation and my path to writing this package: https://vaniasin.com/chh-making-clickhouse-ch-go-user-friendly/
• Go package: https://github.com/nikita-vanyasin/chh

Do you think it is worth including as part of ch-go package? I can prepare a PR 👌🏻

[SpencerTorres]

Copying my Slack response here:

Hey thanks for making this and writing a blog post, it's good to get more content out there about these lower level drivers.

Part of your description says this:

a bit more fancy while not losing performance

I would like to know exactly how much overhead it really adds. I'm sure it's very little, but with ch-go every cycle and allocation counts. As (relatively) ugly as the SELECT queries are, they are as minimal as can be. In your blog post you mention a scenario where having 30+ high performance ch-go queries would be hard to maintain, but if the queries were important enough to require ch-go then I think they would be maintained well enough to not require such a wrapper.

I'm cautious about adding (and maintaining) another usage pattern to the driver itself, since I think it would lead to even more confusion from the users as to what the preferred implementation is. However, I think it would be fair to perhaps link to your module in the README as an optional layer of abstraction that the user can choose to use.

The clickhouse-go module should ideally be this thin wrapper, but we trade performance for convenience there