[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	19251	19252
Failures	22839	22838
Partial Successes1	5465	5465

	Main	PR
Successful	45.7377%	45.7401%
Failures	54.2623%	54.2599%

${\color{lightgreen}Progressions (1)}$

subselect

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

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: 3f70a0b: 13 test cases ran, 11 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans core database behavior including commits, rollback and recovery, persistence across branching and reopening, concurrent reads and writes, retry and error handling, prepared-query compatibility, dependency resolution, compilation, static checks, race-enabled tests, and driver integration. Overall, ordinary data workflows and resilience paths remain healthy, with a pre-existing compatibility gap around SQL prepared queries.

Safe to merge — the observed prepared-query failures are medium-severity, pre-existing compatibility issues outside this PR’s dependency-only changes, with no regression or PR-attributable failure identified. They are flags for later remediation rather than merge blockers.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	After a commit request was rejected, the data was rolled back, retried safely, and still present after reopening the database.
✅	—	General	A bad statement was rejected, later work was blocked clearly until the transaction ended, and the transaction rolled back without saving the failed write. The same connection then handled a prepared query successfully.
✅	—	General	The database keeps prepared statements and transaction state separate after a failed request, so later valid SQL can be handled normally. A live replay was unavailable because the local database services and Go toolchain were not running.
✅	—	General	Reads stayed complete and consistent while another session created, committed, checked out, and merged a branch. Reopening the database showed the same 20 rows on the main branch.
✅	—	General	The failed write was rolled back, the immediate retry was rejected, and a later valid write committed exactly one row.
✅	—	Rev	The updated dependencies resolved to the versions required by the pull request, their checksums were verified, and the module files stayed unchanged.
✅	—	Rev	The project compiled across all packages, and the code checks completed successfully with the committed dependency files unchanged.
✅	—	Rev	The core unit and integration tests passed with race detection enabled. No test failures, panics, race reports, or timeouts were found.
✅	—	Rev	The Dolt engine compatibility suite finished successfully, including concurrent sequence inserts and versioned query checks.
✅	—	Rev	The complete Go driver integration suite connected to the locally built server and passed all tests without protocol errors, connection failures, or timeouts.
✅	—	Storage	The table kept its merged value after the database was branched, merged, closed, and reopened.
⚠️		General	The direct client returned an error saying that PREPARE and EXECUTE are not supported. The Go driver accepted its Prepare call, so the two client paths did not provide compatible prepared-query behavior.
⚠️		Query	The table setup, regular queries, function query, and transaction commit worked. The valid prepared query then returned an error saying that PREPARE is not supported, so the complete SQL workflow did not finish.

Additional Findings Details

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

🟡 Prepared queries behave differently by client

• Severity: Medium
• Description: The direct client returned an error saying that PREPARE and EXECUTE are not supported. The Go driver accepted its Prepare call, so the two client paths did not provide compatible prepared-query behavior.
• Impact: Clients that use SQL PREPARE and EXECUTE cannot run those queries, while clients using the extended protocol may succeed. This can block prepared-query workflows for affected PostgreSQL clients, but no data loss or security exposure was found.
• Steps to Reproduce:
  1. Create a table with a small integer key and insert rows including 0 and the maximum 32-bit integer.
  2. From a direct PostgreSQL client, prepare a parameterized SELECT for the key and execute it with 0 and NULL.
  3. From the Go SQL driver, prepare and execute an equivalent parameterized SELECT against the same local database.
  4. Compare the returned rows and errors from both clients.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The SQL parser dispatches tree.Prepare nodes to nodePrepare in server/ast/convert.go:190-191. server/ast/prepare.go:23-29 shows that nodePrepare returns NotYetSupportedError("PREPARE is not yet supported") for every non-nil PREPARE statement, so SQL-level PREPARE can never reach execution. The extended PostgreSQL protocol is a separate path: ConnectionHandler.handleParse in server/connection_handler.go:656-729 calls DoltgresHandler.ComPrepareParsed, and handleBind in lines 760-816 calls ComBind to build a bound plan. DoltgresHandler.ComPrepareParsed in server/doltgres_handler.go:166-217 delegates to the engine and returns a prepared node, which explains why pgx/libpq driver calls can accept Prepare even while SQL PREPARE fails. The recorded comparison observed exactly this split, although the later standalone rerun was blocked by the missing Go toolchain and unavailable nested server. The smallest practical fix is to implement SQL PREPARE/EXECUTE support in the existing AST path, or explicitly route SQL PREPARE through the same prepared-plan machinery; do not claim the dependency bump fixes it.

Evidence Package

• text/BF-INTEGRATION-1/prepared-query-client-comparison.txt — 2 KB

🟡 Prepared queries cannot run

• Severity: Medium
• Description: The table setup, regular queries, function query, and transaction commit worked. The valid prepared query then returned an error saying that PREPARE is not supported, so the complete SQL workflow did not finish.
• Impact: Applications that use PostgreSQL prepared queries receive an error instead of the requested results. Other query forms continue to work, so users can often use a direct query as a workaround.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL service.
  2. Create getting_started.employees and insert a few employee rows.
  3. Run a filtered and ordered query, a built-in function query, and an update inside a committed transaction.
  4. Run PREPARE employee_lookup(integer) AS SELECT first_name FROM getting_started.employees WHERE id=$1.
  5. Observe that the prepared query returns an unsupported-feature error instead of executing.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production path for a SQL PREPARE statement is server/ast/prepare.go:23-29. nodePrepare first permits a nil node, but for every non-nil tree.Prepare it immediately returns NotYetSupportedError("PREPARE is not yet supported") and never builds or returns a prepared statement. This directly explains the observed PostgreSQL error and means any valid SQL PREPARE statement fails regardless of its table, parameter type, or query body. The PR context shows only go.mod and go.sum changed: github.com/dolthub/dolt/go and github.com/dolthub/go-mysql-server versions and checksums were updated. Because server/ast/prepare.go is outside that diff, the smallest practical fix is to implement the existing nodePrepare path (or restore a supported implementation) in that file; changing the dependency versions alone does not address it.

Evidence Package

• text/QUERY-1/prepared-query-failure.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.43	-1.83
select_random_points	0.72	0.7	-2.78
select_random_ranges	1.01	1.03	1.98
table_scan_postgres	484.44	493.24	1.82
types_table_scan_postgres	1213.57	1235.62	1.82

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.25	3.25	0.0
oltp_write_only	7.04	7.04	0.0
types_delete_insert_postgres	7.17	7.17	0.0