[auto-bump] [no-release-notes] dependency by elianddb

[coffeegoddd]

☕ An Automated Dependency Version Bump PR 👑

Initial Changes

The initial changes contained in this PR were produced by `go get`ing the dependency.

```
$ go get github.com/dolthub//go@
```

Before Merging

This PR must have passing CI and a review before merging.

[itoqa]

Commit: 025f345: 14 test cases ran, 1 failed ❌, 11 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans database value handling across boundary and malformed inputs, prepared statements, comparisons, SQL modes, error recovery, repeated updates, grouped reporting, and dependency reproducibility. It exercises both normal application flows and edge-case compatibility behavior, with broad evidence that core paths remain healthy alongside a prepared-query data-format regression.

Merge with caution — the PR introduces a medium-severity compatibility regression in prepared-statement text results, which can return altered application values to clients. The other grouped-query failures are unrelated to this change and are flag-for-later observations rather than merge drivers.

Tests run by Ito

Result	Severity	Type	Description
❌		Parse	The prepared streaming query returned values such as 'Evil Bob', 'evilbob@gmail.com', and 'abc' instead of Evil Bob, evilbob@gmail.com, and abc. The direct SELECT and the database/sql prepared lookup for Jane Doe passed, so the failure is specific to the client-visible prepared streaming result path exercised by the integration check.
✅	—	General	The smallest and largest signed values, plus the largest unsigned value, were returned exactly through prepared queries. The matching literal comparisons also returned the expected rows, so users do not see sign changes or lost digits at these limits.
✅	—	General	Empty, boundary, and malformed typed values stayed on the expected conversion path. The database service was healthy, and the focused bind and timestamp checks passed; the browser error only came from using HTTP against a MySQL connection.
✅	—	General	Queries using bound values returned the same rows as equivalent typed SQL literals for numeric, date and time, binary, JSON, and NULL values.
✅	—	General	Queries accepted under empty and ANSI_QUOTES modes returned the expected values, while invalid grouped queries under ONLY_FULL_GROUP_BY were rejected with the expected error.
✅	—	General	Prepared queries returned the expected signed and unsigned numbers, binary data, dates, times, bits, JSON, and empty values. The database driver also completed its query and update checks without changing those values.
✅	—	General	The same prepared update used the first value, then the second value, without mixing them together. Repeating the second update made no extra change, and the final rows had the expected values.
✅	—	Bind	Prepared statements preserved numeric, binary, text, BIT, date, year, datetime, and timestamp values. Invalid values returned the expected errors, and database/sql query and execute flows passed.
✅	—	Driver	The application prepared a statement, applied an update, read the expected rows, and completed cleanup without errors.
✅	—	Rev	TIME values sorted in duration order, including negative and long values, and all equality, range, BETWEEN, NULL, and prepared-parameter checks returned the expected rows.
✅	—	Rev	Malformed SQL, unknown columns, invalid grouping, and unterminated strings returned clear database errors. A valid query worked after each error, and the server showed no panic or stack trace; the mixed comparison was accepted using normal MySQL conversion rules.
✅	—	Rev	The project selected the intended Vitess revision, verified its checksums, and passed the full Go test suite. The same result held with an isolated module cache.
⚠️		General	The direct grouped query returned SQL error 1140 under ONLY_FULL_GROUP_BY instead of returning the groups that passed HAVING with correct ranks, running totals, and row numbers.
⚠️		Group	The grouped report query shows a SQL error instead of returning the groups that pass the filter and their rank, running total, and row number.

Additional Findings Details

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

🟡 Grouped queries fail when windows follow HAVING

• Severity: Medium
• Description: The direct grouped query returned SQL error 1140 under ONLY_FULL_GROUP_BY instead of returning the groups that passed HAVING with correct ranks, running totals, and row numbers.
• Impact: Queries that combine grouped HAVING filters with running totals or ranks can fail instead of returning results. Users can work around this by filtering the groups in a separate query first.
• Steps to Reproduce:
  1. Create grouped rows with several group keys and values.
  2. Enable ONLY_FULL_GROUP_BY and run a query that groups by the key, filters with HAVING, and computes a window rank or running total over the grouped rows.
  3. Observe SQL error 1140 instead of the surviving groups and their window values.
  4. Run an equivalent query that puts the GROUP BY and HAVING in a derived table before the window expressions; that query returns the expected rows.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The local MySQL-compatible server reproduced the failure on the direct query and returned the expected filtered groups for the explicitly staged equivalent. In sql/analyzer/validation_rules.go:238-354, validateGroupBy walks GroupBy, Project, Sort, and related nodes and applies ONLY_FULL_GROUP_BY dependency checks. The window-specific validation at sql/analyzer/validation_rules.go:981-1003 calls checkForNonAggregatedColumnReferences for each plan.Window; when it sees a non-window aggregate alongside a window aggregate that references a column, it returns ErrNonAggregatedColumnWithoutGroupBy. That error is formatted as MySQL error 1140 by sql/errors.go:581-585. For this test's explicit GROUP BY query, the analyzer should validate the grouped input before the window expressions rather than treating the window column reference as an implicit all-rows grouping violation. The smallest practical fix is to preserve the explicit GROUP BY context when applying the window check, or narrow checkForNonAggregatedColumnReferences so it rejects only a genuinely implicit/all-rows aggregate query. Add a regression test covering the direct GROUP BY/HAVING/window form and the first, middle, and last group-removal cases.

Evidence Package

• text/BF-ORDER-2/BF-ORDER-2-grouped-window-evidence.txt — 4 KB

🟡 Grouped window query returns an error

• Severity: Medium
• Description: The grouped report query shows a SQL error instead of returning the groups that pass the filter and their rank, running total, and row number.
• Impact: Users running a valid grouped report query may receive a SQL error instead of the groups and ranking results they requested. They can work around it by rewriting the query to stage the grouped results first.
• Steps to Reproduce:
  1. Start the local MySQL-compatible server and enable ONLY_FULL_GROUP_BY for the session.
  2. Create grouped input rows with groups such as alpha, beta, and gamma, then run a query that groups by grp, filters with HAVING SUM(amount) >= 20, and calculates RANK, a running SUM, and ROW_NUMBER window values.
  3. Observe that the direct query returns SQL error 1140 instead of rows.
  4. Run the equivalent query after materializing the grouped and filtered rows in a derived table; observe alpha=25 and gamma=41 with the expected window values.
• Stub / mock content: A disposable local database and table were used on the MySQL-compatible test server. No stubs, mocks, route interception, or query bypasses were applied.
• Code Analysis: The failure is supported by the production analyzer, not only by the runtime error. In sql/analyzer/validation_rules.go:945-963, validateAggregations walks both GroupBy and Window nodes when aggregation is present. For a Window node, line 955 calls checkForNonAggregatedColumnReferences. That function in sql/analyzer/validation_rules.go:985-1003 looks for any projected aggregate with Window() == nil and then searches the window expressions for a column reference. When it finds one, lines 989-992 return sql.ErrNonAggregatedColumnWithoutGroupBy, even though the tested statement has an explicit GROUP BY. The same error is defined as MySQL error 1140 in sql/errors.go:581-585. The separate validateGroupBy rule at sql/analyzer/validation_rules.go:238-354 correctly distinguishes explicit grouping from the no-GROUP-BY case, but the window validation path does not preserve that distinction. The smallest practical fix is to make the window-specific check apply only when the analyzed plan represents implicit/all-rows grouping, or otherwise carry the explicit GroupBy context into that check, then add a regression test for explicit GROUP BY plus HAVING and window expressions.

Evidence Package

• text/GROUP-1/grouped-window-query.txt — 2 KB

Tip

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

[itoqa]

Ito Diff Report — 025f345 → 9b2af38: 11 test cases ran, 11 passing ✅.

Diff Summary

The run covered core date arithmetic and text-trimming behavior, including valid operations, invalid inputs, exact whitespace preservation, nested expressions, window-derived values, NULL handling, and continued connection usability. This represents healthy happy-path, edge-case, error-handling, and integration coverage for the changed behavior.

Safe to merge — the exercised interval and trimming behavior is healthy, with no PR-attributable regressions or new failures. Previously passing areas were not rerun, but the omitted historical failures were explicitly unrelated to this change and are flag-for-later rather than merge blockers.

Tests run by Ito

Result	State	Severity	Type	Description
✅	Passing	—	General	Date arithmetic returned the correct dates, while moving the interval into a standalone projection returned the expected error. The SQL connection stayed usable afterward.
✅	Passing	—	General	Trimming the first value from a window kept the correct leading and trailing spaces for all three directions. Direct NULL values stayed NULL, the SQL connection remained usable, and cleanup finished successfully.
✅	Passing	—	General	Nested trimming removes spaces from the requested side and keeps spaces on the other sides. The same database connection also handled a follow-up date calculation.
✅	Passing	—	General	Invalid interval expressions are rejected with a clear error, while valid date arithmetic still returns the correct date. The same database connection stays usable after each rejected query.
✅	Passing	—	Interval	Running a standalone interval returned the expected invalid-use error instead of crashing the SQL service. A follow-up date calculation still worked, so the connection remained usable.
✅	Passing	—	Interval	Adding one day to 2024-01-01 returned 2024-01-02, and the next query also succeeded.
✅	Passing	—	Interval	Adding one day to January 1 returned January 2, and subtracting one day from January 2 returned January 1. A follow-up date calculation also succeeded, so the SQL connection stayed usable.
✅	Passing	—	Trim	The database removed all spaces around foo and returned exactly foo. A follow-up query also succeeded on the same connection.
✅	Passing	—	Trim	Removing spaces from the leading side returned foo followed by exactly three trailing spaces. The database connection also worked for a follow-up query.
✅	Passing	—	Window	A value with spaces on both sides was trimmed to exactly a.
✅	Passing	—	Window	The query removed the two leading spaces from the window value and kept both trailing spaces, returning a exactly.
⏸️	Skipped	—	General	The smallest and largest signed values, plus the largest unsigned value, were returned exactly through prepared queries. The matching literal comparisons also returned the expected rows, so users do not see sign changes or lost digits at these limits.
⏸️	Skipped	—	General	Empty, boundary, and malformed typed values stayed on the expected conversion path. The database service was healthy, and the focused bind and timestamp checks passed; the browser error only came from using HTTP against a MySQL connection.
⏸️	Skipped	—	General	Queries using bound values returned the same rows as equivalent typed SQL literals for numeric, date and time, binary, JSON, and NULL values.
⏸️	Skipped	—	General	Queries accepted under empty and ANSI_QUOTES modes returned the expected values, while invalid grouped queries under ONLY_FULL_GROUP_BY were rejected with the expected error.
⏸️	Skipped	—	General	Prepared queries returned the expected signed and unsigned numbers, binary data, dates, times, bits, JSON, and empty values. The database driver also completed its query and update checks without changing those values.
⏸️	Skipped	—	General	The same prepared update used the first value, then the second value, without mixing them together. Repeating the second update made no extra change, and the final rows had the expected values.
⏸️	Skipped	—	Bind	Prepared statements preserved numeric, binary, text, BIT, date, year, datetime, and timestamp values. Invalid values returned the expected errors, and database/sql query and execute flows passed.
⏸️	Skipped	—	Driver	The application prepared a statement, applied an update, read the expected rows, and completed cleanup without errors.
⏸️	Skipped	—	Rev	TIME values sorted in duration order, including negative and long values, and all equality, range, BETWEEN, NULL, and prepared-parameter checks returned the expected rows.
⏸️	Skipped	—	Rev	Malformed SQL, unknown columns, invalid grouping, and unterminated strings returned clear database errors. A valid query worked after each error, and the server showed no panic or stack trace; the mixed comparison was accepted using normal MySQL conversion rules.
⏸️	Skipped	—	Rev	The project selected the intended Vitess revision, verified its checksums, and passed the full Go test suite. The same result held with an isolated module cache.

Tests that are no longer relevant

Below are tests that previously ran and are no longer relevant:

Type	Test	Description
General	Grouped queries fail when windows follow HAVING	Dropped because The prior grouped/window ordering scenario is outside this commit's interval and TRIM surface; current interval boundary and propagation probes cover the changed behavior instead.
Group	Grouped window query returns an error	Dropped because This commit changes interval validation and TRIM parsing/evaluation, not grouped window behavior; the prior grouped-window test has no applicable changed surface.
Parse	Prepared queries return quoted text values	Dropped because The current parser change is limited to omitted-pattern TRIM direction handling; the prior broad SQL parsing scenario is not applicable to this diff.

Tip

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