get_columns_in_relation runs `desc` inside an explicit transaction → error 5305 on StarRocks 3.5+

[jecos]

Summary

starrocks__get_columns_in_relation runs a desc <table> statement while dbt has an explicit transaction open (auto_begin=True). On StarRocks 3.5+, desc is not in the statement whitelist allowed inside an explicit transaction, so the call fails with:

5305 (25P01): Getting analyzing error. Detail message: Explicit transaction only support begin/commit/rollback/insert/update/delete/set/select statements.

This breaks any model/test/macro that calls adapter.get_columns_in_relation() (e.g. several dbt_utils tests, custom generic tests, and snapshots). The same project works fine against StarRocks 3.4, because the explicit-transaction whitelist enforcement was introduced/tightened on the 3.5 line.

Versions

• dbt-starrocks: 1.9.0 (the offending desc statement is still present on main / 1.11.0)
• dbt-core: 1.9.10
• StarRocks server: 3.5.17-041cd01 — fails; 3.4 — works
• Python: 3.10

Root cause

dbt/include/starrocks/macros/adapters/columns.sql → starrocks__get_columns_in_relation issues two statements:

{% call statement('get_columns_in_relation', fetch_result=True) %}
    select ... from INFORMATION_SCHEMA.columns where ...   -- OK: SELECT is whitelisted
{% endcall %}
...
{% call statement('desc_columns_in_relation', fetch_result=True) %}
    desc `{{ relation.schema }}`.`{{ relation.identifier }}`  -- REJECTED: desc not in the whitelist
{% endcall %}

dbt-core's statement macro defaults to auto_begin=True, and StarRocksConnectionManager does not override the transaction handling, so the first statement() call opens a real BEGIN. The subsequent desc then executes inside that transaction and StarRocks 3.5 rejects it.

The desc query is only used to resolve inner types of array/struct/map columns (init_type_map / get_type_by_desc); the column names/types otherwise come from INFORMATION_SCHEMA.columns.

Reproduction

Server-side, with no dbt involved (raw MySQL connection against StarRocks 3.5.17):

BEGIN;
DESC `mydb`.`mytable`;
-- ERROR 5305 (25P01): Explicit transaction only support begin/commit/rollback/insert/update/delete/set/select statements.

Via dbt — any generic test that introspects columns, e.g.:

sources:
  - name: mydb
    tables:
      - name: mytable
        tests:
          - dbt_utils.unique_combination_of_columns: ...

or any custom test/macro calling {{ adapter.get_columns_in_relation(model) }} errors with 5305.

Context: StarRocks 3.5 transaction whitelist

The error text matches StarRocks PR #63722 ("Allow SELECT/SET in explicit transactions", merged to branch-3.5/4.0), which enumerates the allowed set as BEGIN/COMMIT/ROLLBACK/INSERT/UPDATE/DELETE/SET/SELECT. A later PR #72954 added SHOW, but DESC/DescribeStmt is still not whitelisted. StarRocks treats this as intended behavior, so the adapter needs to avoid emitting desc inside a transaction.

Suggested fixes (either works)

1. Run column introspection outside the transaction — pass auto_begin=False to the statement() calls in starrocks__get_columns_in_relation (metadata reads shouldn't be inside a write transaction).
2. Drop the desc query and build columns from INFORMATION_SCHEMA.columns alone (a plain SELECT, allowed in a transaction). This loses precise inner types for array/struct/map, but those are available via INFORMATION_SCHEMA for most use cases.

Workaround

A project-level override of starrocks__get_columns_in_relation that uses only the INFORMATION_SCHEMA.columns SELECT (no desc) resolves the error and works against both 3.4 and 3.5.x.

[jaogoy]

1. Using SELECT ... FROM INFORMATION_SCHEMA.xxx is the recommended way rather than DESC xxx. Only when the former can't work for some specific situations.
2. auto_begin=False should also support columns. It will be a long time before SR supports some queries in a transaction, even SR won't support it.