trinodb / trino-python-client

Python client for Trino
Apache License 2.0
328 stars 163 forks source link

Support setting session properties on a individual statement #339

Open mdesmet opened 1 year ago

mdesmet commented 1 year ago

Description

Sometimes people want to set certain session properties on a single statement. This feature makes this much easier to manage as it avoids the state management involved with SET to the desired value and resetting back to the original value (which might not be the default value so RESET cannot be used).

Other DBMS have similar feature, eg. statement_params in Snowflake.

Some common use cases are setting different limits on query time or INSERT OVERWRITE in hive.

Non-technical explanation

Release notes

( ) This is not user-visible or docs only and no release notes are required. ( ) Release notes are required, please propose a release note for me. (*) Release notes are required, with the following suggested text:

* Support setting session properties on individual statements
hashhar commented 1 year ago

@ebyhr opinions? I'm not in favour of this since it makes it harder to reason about how session properties at connection and cursor level interact and what happens with cursor reuse.

Note that most other db-api clients follow the creating separate Connection per unique set of session properties mechanism.

ebyhr commented 1 year ago

@hashhar I have the same opinion as you wrote. No strong opinion though.

mdesmet commented 1 year ago

I'm not in favour of this since it makes it harder to reason about how session properties at connection and cursor level interact and what happens with cursor reuse.

The counter argument is that this makes setting session properties for individual queries much easier for the end user. It also pretty transparent as the property is only valid for that cursor instance.

I don't think creating separate connections makes sense, I have the opposing view this actually adds complexity for the user. Also what if at some point we introduce transactions (Iceberg). It still makes sense to apply separate session properties onto a certain query within the same connection in that case. This is obviously already possible with SET and RESET session property. The advantage of this method is that the user doesn't have to keep track of the session property state (which is not necessarily the default when using RESET).