Here’s a gentle change request with details—thanks for the effort so far, and please keep going:

• parser/sql/engine/dialect/doris/src/main/java/org/apache/shardingsphere/sql/parser/engine/doris/visitor/statement/type/DorisDALStatementVisitor.java: In visitShowTransaction, add result.addParameterMarkers(getParameterMarkerSegments()) (like other SHOW visitors) so SHOW TRANSACTION ... WHERE label=? keeps parameter metadata.
• parser/sql/statement/dialect/mysql/src/main/java/org/apache/shardingsphere/sql/parser/statement/mysql/dal/show/MySQLShowTransactionStatement.java: Prefer storing FromDatabaseSegment (consistent with other SHOW statements) and override getAttributes() to set FromDatabaseSQLStatementAttribute / AllowNotUseDatabaseSQLStatementAttribute etc., so the FROM clause position and routing/database requirements are honored rather than being ignored or defaulted.
• test/it/parser/src/main/java/org/apache/shardingsphere/test/it/sql/parser/internal/asserts/statement/dal/dialect/mysql/MySQLDALStatementAssert.java: Add an assertion branch for MySQLShowTransactionStatement to verify fromDatabase and where, ensuring the new XML cases actually validate the parsed output.

These tweaks will align the new syntax with existing behavior and prevent loss of placeholder/routing info.

Here are a few friendly change-request suggestions to get this over the line:

• Please wire SHOW TRANSACTION into backend execution: add a matching admin executor (and factory wiring, similar to MySQLShowTablesExecutor) so the parsed statement can actually run in proxy/JDBC; consider adding an e2e/admin test to prove the result shape.
• Revisit the grammar constraint: the current rule requires WHERE. If Doris allows SHOW TRANSACTION [FROM db] without WHERE, expand the rule and add a parser case to cover it.
• Verify downstream handling of the new array literal → ListExpression: add a small parser-to-binder/route regression test (e.g., encrypt/shadow rewrite path) to ensure bracketed arrays aren’t misinterpreted as IN lists or otherwise altered.
• Add a dedicated assertion/test for MySQLShowTransactionStatement covering both FROM db and WHERE variants, and include parameter-marker scenarios if supported.

Thanks for the solid parser work—once these pieces are in, this feature should be ready.

Here are the suggestions (hope they help—once refined it should be close to merge-ready):

• proxy/backend/dialect/mysql/handler/admin/executor/show/MySQLShowTransactionExecutor.java currently always returns an empty result and ignores both WHERE and FROM database filtering, so it swallows the request and doesn’t solve the root need (returning transaction
  status). Please wire it to real transaction/load job data (or at least throw a clear “not supported” error instead of an empty set), and apply FROM/WHERE filtering. Add tests covering data present/absent and filter-miss cases.
• The same executor only returns 6 columns (TransactionId, Label, Database, TransactionStatus, LoadStartTime, LoadFinishTime), which doesn’t match the Doris SHOW TRANSACTION reference (missing columns like Coordinator, LoadJobSourceType, PrepareTime, CommitTime, Reason,
  ErrorReplicasCount, ListenerId, TimeoutMs, etc.). Please align the column set and types with the Doris protocol, and assert column names/types in tests to avoid client compatibility issues.
• MySQLShowTransactionExecutorTest only checks “empty data, metadata shape” and misses key behaviors: WHERE filtering, actual data row(s), and full column set. After wiring the logic, please add tests for ID/label filter hit/miss, with/without FROM behavior, and
  asserting a real transaction row.
• Optional: if you can’t hook to real data yet, prefer an explicit error (e.g., UnsupportedOperationException or a user-facing message) instead of an empty result, to avoid misleading users into thinking there are no transactions.

Thanks for pushing Doris grammar and cases in the right direction—keep it up!

Core reason: each revision tweaked grammar, columns, and empty-result tests but never fixed the root issue—returning real SHOW TRANSACTION data. The executor still returns an empty set, filtering is minimal (Column=Literal only) and can throw type exceptions, and tests only cover empty results/metadata, so the core functionality is missing and defects stay hidden.

Recommendation: pause coding and analyze first, instead of piling more changes:

• Clarify requirements: where to fetch SHOW TRANSACTION data (Doris transaction/load-job source), and ensure column fields/order/types exactly match the Doris protocol.
• Design the data path: how to obtain the transaction list from metadata/engine, how FROM/WHERE (ID/label) should affect results; if unsupported, return an explicit “not supported” error instead of an empty set.
• Fix filtering and type handling: handle case-insensitive names, stringified numbers, non-equality cases, and avoid ClassCastException.
• Define a test checklist: data rows, filter hit/miss, column name/type assertions, and error/unsupported paths.

Get this analysis and design straight before further coding; otherwise the PR will keep being unmergeable.

Here’s feedback for the PR author:

Key issues

• MySQLShowTransactionExecutor#loadTransactions() just throws UnsupportedOperationException, so SHOW TRANSACTION will always fail at runtime; the root goal (supporting the statement) isn’t achieved.
• Syntax mismatch: Doris docs specify SHOW TRANSACTION [FROM ] WHERE id=<...> | label=<...>; and require WHERE. The executor enforces WHERE (correct), but the added supported SQL includes a no-WHERE case, which will now throw IllegalArgumentException, conflicting
  with Doris syntax and your executor behavior.
• Runtime regression: Moving from “parse unsupported” to “parse ok but always fails” is a worse user experience.

Suggestions

1. Align syntax and cases: Drop/adjust the no-WHERE Doris SQL case; keep only forms with WHERE id=... or WHERE label=... as per docs.
2. Implement loadTransactions(): Fetch transaction info from Doris FE (or an existing API) and populate the 12 columns; if you can’t support it yet, don’t register the executor in the factory (or return an empty result with a clear “not supported” message) to avoid
   throwing UnsupportedOperationException.
3. Compatibility behavior: For missing/incomplete databases, return an empty result (unless syntax is invalid), matching SHOW conventions.
4. Tests: Adjust/add cases to cover id/label filters hit/miss, remove the no-WHERE case, and validate the final behavior.
5. If execution can’t be supported now, consider keeping only the parser-level additions (grammar/AST/assert) and explicitly not enabling the executor path to avoid confusing users.