feat(editor): offer Execute All Statements in the Execute button's menu

[datlechin]

Fixes #2230.

Root cause

Execute All Statements is not a missing feature. It ships today and it is correct: runAllStatements() splits the tab with SQLStatementScanner.allStatements, then executeMultipleStatementsWithParameters takes a single lease on the tab's connection, runs the statements in order, and rolls back and stops on the first failure (QueryExecutionCoordinator+Parameters.swift:346-420).

What it did not have was a way to reach it from the editor. It had exactly two entry points, both outside the editor pane: the Query menu and Cmd+Shift+Return. The Execute split button, which is the control people actually reach for, offered only Execute Without Limit (QueryEditorView.swift:143-149). So the workaround is the one the reporter describes: select the whole tab by hand, then press Execute.

That workaround dispatches identically to the command that was already there. runQuery runs the selection when there is one and otherwise only the statement under the caret (MainContentCoordinator.swift:899-917), then splits that text with the same scanner and calls the same dispatchStatements. So this is an affordance gap, not a semantics bug.

This is the second time it has been asked for. #770 requested "a dedicated button or shortcut to execute the entire script at once", and 823ddd6 shipped only the shortcut.

The fix

Add Execute All Statements as the first item of the existing Execute pull-down, wired to coordinator.runAllStatements(), the same method the Query menu invokes.

Two source lines of behaviour, plus a test:

• QueryEditorView.swift: a new optional onExecuteAllStatements callback and the menu item, ordered above Execute Without Limit to mirror the Query menu.
• MainEditorContentView.swift:405: passes coordinator.runAllStatements().

Design notes, since a few of these were deliberate rather than incidental:

• A pull-down item, not a seventh toolbar button. This is where TablePlus puts Run All ("the dropdown adjacent to the Run Current button"), and the HIG's pull-down guidance is to use one "without requiring additional buttons in your interface". The toolbar already carries six controls.
• The primary action still runs the selection or the caret's statement. TablePlus made Run All the primary button once, shipped data loss, and reversed it (TablePlus#255).
• Title unchanged. It reuses the shipped string, which the Query menu and Settings > Keyboard already show. Postico calls it "Execute All Queries" and Sequel Ace "Run all queries"; every comparable client says All, none says Script.
• No icon. The HIG asks for uniform treatment across a group, and the sibling item is text only.

Verified

Run through verify.sh against the branch, serially:

Step	Verdict
generate	PASS
build (Debug)	PASS
uitest QueryExecuteMenuUITests	PASS, 2 of 2 cases
lint (3 changed paths)	0 violations

The new suite has two cases, and the second exists because the first is not enough on its own. onExecuteAllStatements is optional, so deleting the wiring at the call site would not be a compile error and a presence-only assertion would stay green. testExecuteAllStatementsRunsEveryStatementInTheTab therefore clicks the item and asserts both statements ran, one result tab each, with nothing selected.

Before and after

Before, the menu held one item, Execute Without Limit. After, it holds Execute All Statements above it. I captured the open menu from the passing UI test and it is attached below by the author, since gh cannot upload images itself.

The page screenshot in docs/features/sql-editor.mdx shows the button closed, so it stays accurate and needs no recapture.

Known limitations

• The menu does not render the key equivalent. Cmd+Shift+Return is attached with .optionalKeyboardShortcut, exactly as the sibling item attaches Cmd+Option+Return, but SwiftUI draws no shortcut column here. Confirmed from the captured screenshot: neither item shows a chord. The shortcut is still discoverable in the Query menu and in Settings > Keyboard.
• Neither item is dimmed on an empty tab, while the Query menu dims all three execute commands on !hasQueryText (MainSplitViewController+MenuValidation.swift:128-134). Both commands already return early on empty text, so this is cosmetic. It is left alone deliberately: the HIG says a menu should stay openable so people can learn the commands it contains, while the adjacent Explain menu disables the whole control, and resolving that inconsistency is a change to a shipped control that does not belong in this PR.
• The UI test reaches the split button through an accessibility identifier on the Menu and a normalized-offset click on the chevron, because the leading half of the control runs the query. It passes locally. The opened menu is scoped to the window rather than matched by identifier, which is the workaround ResultTabPinUITests records for the CI runner exposing a just-opened menu without one.

Not included

The investigation verified five other defects in this subsystem. None ship here, because this change adds a second entry point to an existing command and creates no new code path. They are reported separately with repros. The one worth naming is that SQLStatementScanner applies backslash string escaping in every dialect, ignoring SqlDialect.requiresBackslashEscapesInSingleQuotes, which merges statements on PostgreSQL and can carry a write past the Safe Mode gate.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
TablePro	🟡 Building	–	Aug 19, 2026, 8:16 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.