with_param

[serprex]

Small wrapper around with_option for impl Serialize + Bind

[slvrtrn]

Aside from the simpler types, the following needs testing:

• Arrays, Maps, Tuples (e.g., common container types that make sense to use in this context).
• DateTime/DateTime64 (IIRC, it requires a specific format like 2022-05-02 13:25:55.123456789, i.e. not exactly ISO timestamp)
• Numeric and named enums
• \t, \r, \n, single quotes, backslashes in the bound strings
• Strings with UTF8 symbols
• Nulls

I'd maybe also not mix it with .with_option method; the proposal from @mshustov looks better IMO (see this comment) - we can add the param_ prefix ourselves internally.

[serprex]

So already found issue with basic tests. String Bind serializes to 'string' with quotes which is correct when interpolating into query string, but for server side parameters the string should be unquoted

Note once a string is contained it is expected to be quoted in params: ClickHouse/clickhouse-connect#159

[loyd]

What's the purpose of Client::with_param? Parameters are specific for queries, not the whole client

[serprex]

Generally, but if someone wants to share parameter between queries queries they can put it on the client

For example, in a multi tenant app, tenantid could be put as a parameter in the function creating client

[loyd]

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 examples.

[loyd]

I'm still trying to figure out the naming here. This one is consistent with with_option, but that name emphasizes the connection with Client::with_option.

For instance, bind mimics sqlx bind.
A simple param() would be more concise. Yep, it's inconsistent for now, but once Client::builder() is introduced, we can have fn option() instead of with_option.

[loyd]

Result<> can be very inconvenient. It can be used in a concise way only inside -> Result functions (q.with_param("a", 42)?.with_param("b", 43)?), but sometimes you want explicitly handle errors with matching inside the function that doesn't return Result, so ? (via the Try trait) cannot be used.

So, I suggest delayed errors in the same way as in the bind() method.

[loyd]

This method must be well documented. Also, we should specify the difference between param() and bind() (probably in a dedicated section on Query and provide links to that section in docs of both methods).