Handle subqueries in dolt_commit_diff_<table>

[Hydrocharged]

Fixes:

• dolt_commit_diff_<table> doesn't work with subselect #3105

Builds upon:

• Added subquery lookups for tables requiring an index, and subquery table function arguments go-mysql-server#3978
• Added tests for subqueries in dolt_commit_diff tables and dolt_diff dolt#11998

The fix is in GMS since it affected Dolt too, so this is just for adding a test

[github-actions]

	Main	PR
Total	42090	42090
Successful	20253	20253
Failures	21837	21837
Partial Successes1	5406	5406

	Main	PR
Successful	48.1183%	48.1183%
Failures	51.8817%	51.8817%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

Commit: 23a7ede: 10 test cases ran, 10 passed ✅.

Summary

The run covered normal change-history comparisons across both supported database diff paths, including correct changed-row results, connection continuity, and reversed comparison direction. It also exercised edge and adversarial cases involving ambiguous commit selections, confirming clear cardinality errors rather than arbitrary results.

Safe to merge — all exercised behaviors passed, with no regressions, new failures, or previously flagged failures attributable to this PR. No merge-blocking risk was identified.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The forward query returned the changed row with value changing from a to b. Reversing the two commits returned the same row in the opposite direction, from b to a, so the query did not falsely reuse the forward result.
✅	—	General	The bounded queries returned the expected changed row. Removing the row limit produced a clear database cardinality error through both supported diff paths.
✅	—	General	Both ambiguous commit queries returned the expected PostgreSQL error, and valid follow-up queries returned the correct diff row.
✅	—	General	Both diff queries rejected an ambiguous commit argument with the expected PostgreSQL error message and SQLSTATE 21000.
✅	—	Cardinality	Both diff queries returned a PostgreSQL cardinality error when the commit subquery returned more than one row.
✅	—	Compatibility	Both diff interfaces returned the expected row for valid commit arguments. Both rejected an ambiguous multi-row commit argument with the required PostgreSQL cardinality error.
✅	—	Diff	After two commits are created, both supported diff queries accept the latest and previous commit subqueries and return the changed row with ID 1.
✅	—	Rev	The diff query rejected an ambiguous commit lookup with SQLSTATE 21000 and an error saying the subquery returned more than one row. It returned no arbitrary diff row.
✅	—	Rev	The database rejected an ambiguous commit query with a clear cardinality error instead of choosing a commit at random.
✅	—	Rev	The database stayed connected, and both diff queries returned the one expected changed row.

Tip

Reply with @itoqa to send us feedback on this test run.

[coffeegoddd]

@Hydrocharged DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.43	2.57	5.76
groupby_scan_postgres	82.96	84.47	1.82
index_join_postgres	2.26	2.22	-1.77
index_join_scan_postgres	1.61	1.61	0.0
index_scan_postgres	467.3	475.79	1.82
oltp_point_select	0.37	0.37	0.0
oltp_read_only	6.43	6.43	0.0
select_random_points	0.73	0.73	0.0
select_random_ranges	1.04	1.04	0.0
table_scan_postgres	475.79	467.3	-1.78
types_table_scan_postgres	1191.92	1191.92	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.36	3.36	0.0
oltp_read_write	13.46	13.46	0.0
oltp_update_index	3.62	3.62	0.0
oltp_update_non_index	3.3	3.25	-1.52
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0

[itoqa]

History reset (rebase or force-push detected). Starting test narrative over.

Commit: 0a14fb3: 9 test cases ran, 9 passed ✅.

Summary

The change is covered across normal commit-difference lookups, direct and history-based selection, prepared queries, and recovery after invalid input. It also exercises edge cases where commit selections are ambiguous, confirming clear errors while preserving valid follow-up operations and expected changed-row results.

Safe to merge — the exercised behaviors are passing with no regressions, new failures, or previously flagged failures attributable to this PR. No merge-blocking application issues were identified; the run is low risk.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	Both diff queries rejected an unclear commit choice with the expected error, and neither returned a changed row.
✅	—	General	The history-selected query returned the same changed row as the direct parent-to-HEAD query, with to_id equal to 1.
✅	—	Cardinality	Both diff queries rejected multiple matching commits with the expected PostgreSQL cardinality error. A valid follow-up query returned the changed row.
✅	—	Diff	The query selected the parent and latest commits from history and returned the expected changed row with id 1.
✅	—	Diff	DOLT_DIFF accepts the parent and latest commit selected from history and returns the changed row with to_id 1.
✅	—	Filter	The direct commit-hash query returned one changed row with to_id 1.
✅	—	Rev	The qualified commit-diff query returned exactly one changed row with to_id equal to 1.
✅	—	Rev	A prepared query with commit values selected from the history and one bound filter ran successfully and returned one changed row with to_id equal to 1.
✅	—	Rev	A query with too many matching commits returned the expected SQL error, and the next valid diff query on the same connection returned row 1.

Tip

Reply with @itoqa to send us feedback on this test run.

[itoqa]

History reset (rebase or force-push detected). Starting test narrative over.

Commit: 734358a: 8 test cases ran, 7 passed ✅, 1 additional finding ⚠️.

Summary

The run covered normal versioned-data comparisons, commit selection, empty and ambiguous inputs, recovery after failed requests, and consistency between two query interfaces, along with full build and test validation. Core behavior and error recovery remain healthy, with one edge case where an empty lookup produces an internal error in one interface instead of an empty result.

Safe to merge — the only observed failure is a medium-severity, non-regression issue explicitly not attributable to this PR, so it is a flag for later rather than a merge blocker. The PR’s exercised behavior showed no new or returning failures.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	Both query forms returned the changed row when the commit lookup found one row. When the lookup found multiple rows, both returned the expected cardinality error with SQLSTATE 21000 and no diff rows.
✅	—	General	A missing commit selection returned no diff rows, even after a valid selection ran first in the same session.
✅	—	General	Invalid diff requests returned the expected cardinality error, and the next valid request in the same session returned the changed row. Both the diff table and DOLT_DIFF function recovered correctly.
✅	—	General	A query with too many selected commits returned the expected cardinality error. The next valid query returned the committed row with to_id 1 in both interface orders, so the earlier failure did not corrupt the result.
✅	—	Diff	Both diff query forms selected the base and change commits and returned the changed row with to_id 1.
✅	—	History	The table diff and DOLT_DIFF query both returned the changed bug6 row with to_id 1 when given the saved base and change commits.
✅	—	Rev	The dependency update compiled successfully, and the complete Go test command finished with no failures.
⚠️		General	The function-based diff query fails with an internal SQL error when its commit subquery returns no rows, while the table-based query returns no rows for the same empty selection.

Additional Findings Details

These findings are unrelated to the current changes but were observed during testing.

🟡 Empty commit selection causes an internal error

• Severity: Medium
• Description: The function-based diff query fails with an internal SQL error when its commit subquery returns no rows, while the table-based query returns no rows for the same empty selection.
• Impact: A filtered diff query can fail with an internal database error when no commit matches, instead of returning an empty result. Callers can work around it by supplying an existing commit hash, but the function interface is unreliable for valid empty lookups.
• Steps to Reproduce:
  1. Create table bug6 with one row, commit a base revision, update the row, and commit the change revision.
  2. Run SELECT to_id FROM dolt_commit_diff_bug6 WHERE to_commit = (SELECT commit_hash FROM dolt.log WHERE 1 = 0) AND from_commit = dolt_hashof('HEAD~'); and observe an empty result.
  3. Run SELECT to_id FROM DOLT_DIFF((SELECT commit_hash FROM dolt.log WHERE 1 = 0), 'HEAD', 'bug6');.
  4. Observe SQLSTATE XX000 with the message received '' when expecting commit hash string instead of an empty result.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The recorded SQL matrix establishes that one-row scalar commit expressions work through both interfaces and that multi-row expressions consistently produce SQLSTATE 21000 with the expected 'more than 1 row' error. The mismatch is isolated to the zero-row function argument: the table query at testing/go/dolt_tables_test.go:1582-1584 expects and receives an empty row set, but DOLT_DIFF with the analogous zero-row expression returns SQLSTATE XX000, 'received when expecting commit hash string'. The local function implementation is supplied by the dependency revisions changed in go.mod, while server/tables/dtables/diff.go only registers the diff table name and contains no DOLT_DIFF argument conversion logic. This points to nil scalar-result handling in the dependency-backed DOLT_DIFF argument path, not to the browser connection or the SQL fixture. The targeted remediation is to preserve the zero-row scalar result as an empty diff input/result, or otherwise short-circuit before commit-hash string conversion; broad changes to diff execution are not needed.

Evidence Package

• text/BF-INTEGRATION-1/BF-INTEGRATION-1-zero-row-diff.txt — 4 KB

Tip

Reply with @itoqa to send us feedback on this test run.

[itoqa]

History reset (rebase or force-push detected). Starting test narrative over.

Commit: 12ca1e9: 11 test cases ran, 11 passed ✅.

Summary

Coverage exercises the database’s change-history behavior across normal updates and commit comparisons, including empty lookups and recovery after invalid ambiguous requests. It also checks edge and adversarial cases such as multiple matching commits, while confirming that valid queries continue returning the expected changed data.

Safe to merge — the run found no PR-attributable regressions or failures across the covered normal, edge, and error-handling behaviors. No merge blocker was identified; overall risk is low.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The query used the newest and immediately preceding commits and returned the row changed between them, from value b to value c.
✅	—	General	After a valid commit lookup returned one changed row, an empty commit lookup returned no rows and no error.
✅	—	General	The diff query returned the expected bug6 row when both commit values came from ordered subqueries. Its result matched the generated table query.
✅	—	General	Both commit-diff query surfaces reject a subquery that returns several commits. They return no diff row and expose the expected PostgreSQL cardinality error.
✅	—	Cardinality	A commit lookup that returns several history rows is rejected with a clear cardinality error instead of choosing one commit silently.
✅	—	Commit	The commit-diff query returned the changed bug6 row with ID 1 when both commit values came from ordered history lookups.
✅	—	Difference	The database accepted commit values from two scalar subqueries and returned the changed bug6 row with ID 1.
✅	—	Empty	The empty commit lookup completed successfully and returned no rows without an error.
✅	—	Reference	The commit-diff query using the current commit and its parent returned the changed row with ID 1.
✅	—	Rev	The qualified public query completed successfully and returned exactly one row with to_id 1.
✅	—	Rev	A query with multiple commit rows returned the expected SQLSTATE 21000 error. The next query in the same session returned one changed row with to_id 1, and the session stayed usable.

Tip

Reply with @itoqa to send us feedback on this test run.