[DRAFT] Support trino operator

[EdenKik]

A dedicated TrinoOperator that directly handles Trino's client protocol.
Instead of relying on XComs as relevant for different SQL databases & engines, TrinoOperator fetches all results in default, allowing developers to decide how to use them.

Trino client protocol [https://trino.io/docs/current/client/client-protocol.html#client-protocol]

closes: #46808
related: #46808

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[potiuk]

I think you should not replace the old ways. Maybe you can add new ways and say create "NativeTrinoOperator" to do things differently. There is a good reason why we have the common sql abstraction and we want all databases to have more or less the same behviour and this is the way we want to promote it with our users: this allows them to easily switch between different datbases - mostly by changing connections.

Happy to review it when it is changed to be "addition".

[EdenKik]

I think you should not replace the old ways. Maybe you can add new ways and say create "NativeTrinoOperator" to do things differently. There is a good reason why we have the common sql abstraction and we want all databases to have more or less the same behviour and this is the way we want to promote it with our users: this allows them to easily switch between different datbases - mostly by changing connections.

Happy to review it when it is changed to be "addition".

There was a dedicated TrinoOperator, which was deprecated in favor of SQLExecuteQueryOperator (Issue #25259).

However, SQLExecuteQueryOperator does not fully support Trino’s client protocol. Trino requires the client to fetch results before finalizing query execution. Without this, Trino cancels the query with a USER_CANCELED error, even when data modifications have been applied. This leads to unreliable data modification handling.

I implemented TrinoOperator as a subclass of SQLExecuteQueryOperator since the required change is minimal, it ensures results are fetched. This approach is consistent with how other databases with unique behaviors are handled in Airflow. For example, TeradataOperator and SnowflakeOperator also inherit from SQLExecuteQueryOperator while implementing their own specifics.

[nevcohen]

I think there is a much simpler solution. The condition here needs to be corrected, to pass the handler, even if the do_xcom_push is Flase.

[potiuk]

Yes. I would rather avoid creating specific operators if it can be done using built-in common.sql operators. Note there are many more operators in common.sql that provide much richer functionality and you would have to subclass them alll to have similar usage - also things like GenericTransfer work by jus providing two connection_ids that create hooks and they are not using "specific" operators - so making surethe "generic" interface handles also Trino in the way that is consistent with others is way better approach.

Snowflake and Teradata operators should not be there, really I think it's an overlook.

[EdenKik]

Currently set this PR as DRAFT.
Opened a specific PR for adding configuration to fetch results within the SQLExecuteQueryOperator, #46997

@potiuk FYI

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.