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

[coffeegoddd]

☕ An Automated Dependency Version Bump PR 👑

Initial Changes

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

```bash
go get github.com/dolthub/[dependency]/go@[commit]
```

[github-actions]

	Main	PR
Total	42090	42090
Successful	19271	19270
Failures	22819	22820
Partial Successes1	5459	5459

	Main	PR
Successful	45.7852%	45.7828%
Failures	54.2148%	54.2172%

${\color{red}Regressions (1)}$

subselect

QUERY:          select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);
RECEIVED ERROR: timeout during Receive

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: 79a6f93: 13 test cases ran, 12 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans database correctness and recovery, including successful reads and updates, transaction rollback and retry behavior, invalid-input handling, concurrent client and session isolation, database-root separation, dependency resolution, and full build validation. It also probes adversarial and edge-case SQL behavior, revealing a limited failure in correlated row-generation queries while related query features remain healthy.

Safe to merge — the only observed failure is a medium-severity, pre-existing database SQL limitation unrelated to this dependency-only PR, with no regression or PR-attributable failure identified. It is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	An update that hit division by zero returned an error and did not change the employee. A valid retry in the same session updated the employee once, and the final query returned the expected name.
✅	—	General	The session returned the expected employee row from the real database, built-in catalog rows from pg_catalog, and a clear error for a missing database. Returning to the user-data schema restored the original employee row.
✅	—	General	After one statement failed, the next insert was rejected until rollback. A later transaction then committed its row normally.
✅	—	General	The session returned the employee row from the normal database, showed built-in catalog objects under the catalog root, and correctly hid the employee table there. Restoring the public root returned the original employee row without stale or mixed data.
✅	—	General	The two clients did not exchange rows or data. The reported errors came from the test connection method, while the application has separate query state for each client.
✅	—	General	Concurrent local sessions kept their database views separate. Normal sessions returned the employee row on all 10 checks, while catalog sessions consistently showed catalog objects and could not see the employee table.
✅	—	General	Two clients repeatedly looked up different employees and each received only the employee it requested. The results stayed correct across all repeated requests.
✅	—	Database	Verified acceptable by independent adversarial review: the observed behavior is intended and documented in this codebase. Review notes: The observed error is consistent with an explicit, pre-existing compatibility limitation: repository code says EXCLUDED references are not resolved and intentionally uses literal values when generating conflict updates. ON CONFLICT itself is reachable, but the claimed EXCLUDED regression is contradicted by that unchanged documentation and implementation, while the PR diff supplies no changed-code …
✅	—	Query	A prepared query accepted a bound employee ID and returned the expected employee, field names, and successful completion status.
✅	—	Query	The query rejected the invalid value "abc" before returning any row, then the same connection successfully returned employee 1001 for a valid value.
✅	—	Rev	The dependency files were verified successfully after selecting the Go toolchain required by the repository. Both upgraded modules resolved to the declared versions, and no checksum or replacement problem was found.
✅	—	Rev	The full Go test suite and package build completed successfully after the repository selected the required Go toolchain. The earlier failure was caused by the local container using an older Go version, not by the dependency changes.
⚠️		Rev	The database returned unsupported syntax: values row(generate_series(1, i.id)) instead of expanding generate_series separately for each input row. The non-correlated generate_series check returned 1, 2, and 3, and the ROWS and RANGE window checks passed, so the failure is specific to the correlated lateral form.

Additional Findings Details

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

🟡 Correlated row generation query fails

• Severity: Medium
• Description: The database returned unsupported syntax: values row(generate_series(1, i.id)) instead of expanding generate_series separately for each input row. The non-correlated generate_series check returned 1, 2, and 3, and the ROWS and RANGE window checks passed, so the failure is specific to the correlated lateral form.
• Impact: Queries that use a per-row set-returning function with LATERAL fail instead of producing their expected rows. Other tested set-returning and window queries still work, so the impact is limited to this SQL pattern.
• Steps to Reproduce:
  1. Create a local table named rev5_items with an integer id column and insert rows with ids 1 and 3.
  2. Run SELECT i.id, g.n FROM rev5_items i CROSS JOIN LATERAL generate_series(1, i.id) AS g(n).
  3. Check the result. The query should return 1 row for id 1 and 3 rows for id 3, but it returns an unsupported-syntax error instead.
• Stub / mock content: The test used a disposable local table and a local-only authentication bypass to connect to the sandbox database. No production data or application response stubs were used.
• Code Analysis: The production code registers the integer, numeric, and timestamp generate_series overloads as set-returning functions in server/functions/generate_series.go:30-39. The integer overloads at lines 44-56 and 91-103 return SetReturningFunctionRowIter instances through int32GenerateSeries and int64GenerateSeries, confirming that the function itself is implemented for normal set expansion. In server/analyzer/optimize_functions.go, lines 45-72 inspect expressions found in the child/source node and record that an SRF exists, while lines 85-124 only mark the Project node with IncludesNestedIters when the SRF is in projection expressions. A correlated LATERAL SRF is in the FROM-side plan and is subsequently represented by the engine as a VALUES row containing generate_series(1, i.id), which the local execution path rejects with the reported unsupported-syntax error. The smallest practical fix is to preserve the correlated FROM-side SRF as a lateral nested iterator, or add the equivalent analyzer/plan rewrite for that specific shape, so the function arguments are evaluated against each outer row before iteration. The PR's go.mod and go.sum changes do not include any of these files or logic.

Evidence Package

• text/REV-5/REV-5-correlated-lateral-evidence.txt — 2 KB

Tip

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

[coffeegoddd]

@coffeegoddd DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.52	2.43	-3.57
groupby_scan_postgres	77.19	75.82	-1.77
index_join_postgres	2.26	2.26	0.0
index_join_scan_postgres	1.61	1.61	0.0
index_scan_postgres	484.44	493.24	1.82
oltp_point_select	0.37	0.37	0.0
oltp_read_only	6.55	6.55	0.0
select_random_points	0.72	0.72	0.0
select_random_ranges	1.01	1.03	1.98
table_scan_postgres	493.24	484.44	-1.78
types_table_scan_postgres	1235.62	1235.62	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.79	1.8
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.25	3.3	1.54
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0

[github-actions]

This PR has been superseded by #3242