Paul Loyd

> do you have an idea how to fix https://github.com/ClickHouse/clickhouse.rs/issues/24? I do, but not ideal ones (with breaking changes in API sadly). Let's continue in #24 if you want to...

Now there is no way to do it, but it is more likely the crate will provide `query_raw()` for such cases

First of all, the only reason why this crate already contains (conditionally!) serde-json is only WA for `WATCH`, which will go away with moving to the `Native` format. Secondly, the...

> query_raw could also cover this issue (even if everybody will be forced to write their own deserializer) - but when? Actually, I think we can implement `query_raw` pretty fast....

The context: this crate uses custom parameters (implemented before CH started to support server-side parameters). Now, server-side parameters can be used, as shown in https://github.com/ClickHouse/clickhouse-rs/issues/142#issuecomment-2341182968 (not an ideal solution, but...

I'm against closing this one and don't think that #243 and this issue are replaceable. Let's start with common statements about our goals regarding the query API (IMO obviously): 1....

According to [docs](https://clickhouse.com/docs/en/sql-reference/data-types/dynamic#binary-output-format) this is encoded as ``` ``` So, it should lead to `deserialize_any` (to ask for the real type from the deserializer). Then, it can be parsed into...

@slvrtrn the `select` benchmark never ends now, need to fix before merging

@slvrtrn at least `examples/usage` fails now. So, the following code: ``` client.query("SELECT count() FROM some").fetch_one::() ``` is invalid now =(

We also need tests for `UUID` (probably, with the human-readable mode it works already). Also, for some implementation of `DecimalX` (the `fixnum` crate for instance). And need to add some...