Exposed method to control the readonly query parameter

[serg-temchenko]

Summary

This PR is meant to improve the control over the readonly option sent by the client to the CH database. Right now, it is defined by some methods like Query::do_execute, but most of the public methods like Query::fetch, Query::fetch_one, or Query::fetch_all don’t have control over this option. This makes it impossible to query the database with queries that contain a lot of columns and require temporary table creation on the database side, which results in the following error:

Code: 164. DB::Exception: db_user: Cannot execute query in readonly mode. (READONLY) (version 24.10.1.2812 (official build))

By adding the changes in this PR, we will gain control over this option, making it possible to request data that requires the creation of temporary tables by CH.

Checklist

• A human-readable description of the changes was provided so that we can include it in CHANGELOG later

[CLAassistant]

All committers have signed the CLA.

[slvrtrn]

As it is now set as true by default, won't this fail with DDLs now?

[slvrtrn]

Thanks for the contribution; it makes sense, given that the read-only param is hardcoded by default. Let's fix the logic (see the comment, CI also confirms that), add some more tests regarding enabled/disabled readonly mode, and maybe an example illustrating the use case.

NB: failing MSRV CI check is supposed to be fixed after #180

[slvrtrn]

At a second glance, would it make more sense just to make it so that .with_option("readonly," "0") overrides the default hardcoded read-only param? In that case, we don't need to have a separate method for that, it will be consistent with other settings usage, and we can just document with_option usage via an example.

[slvrtrn]

CC @loyd @serprex have a look please ^

[serg-temchenko]

Hey @slvrtrn.

would it make more sense just to make it so that .with_option("readonly," "0") overrides the default hardcoded read-only param?

Sure, I can check/extend tests and docs. But I’m just thinking if overwriting with 0 is the proper way to go, I mean including the readonly option all the time, since afaik it can be configured on the DB side. Basically, the user can be configured with the required access level. It will just limit the client and require handling that on both sides, which is a bit redundant and needs additional maintenance. But, as long as I can perform SELECT queries without encountering confusing exceptions, I'm okay with that :)

Based on this code with hardcoded flag and this PR, I assume it will not overwrite it by default if it is already present in the options.

[slvrtrn]

Perhaps we can just remove readonly setting, which is enforced by default; IIRC, no other language client does that. Maybe this approach will be even more flexible: #184 (readonly can still be attached using with_option)

[serg-temchenko]

Sure, this will work as well. Thanks.