[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	18408	18406
Failures	23682	23684
Partial Successes1	5327	5327

	Main	PR
Successful	43.7349%	43.7301%
Failures	56.2651%	56.2699%

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

copyselect

QUERY:          drop table test3;
RECEIVED ERROR: Doltgres sent additional messages after ReadyForQuery

random

QUERY:          (SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1)
INTERSECT
(SELECT unique1 AS random
  FROM onek ORDER BY random() LIMIT 1);
RECEIVED ERROR: expected row count 0 but received 1

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. ↩

[github-actions]

	Main	PR
covering_index_scan_postgres	2070.65/s	2142.24/s	+3.4%
groupby_scan_postgres	150.47/s	154.02/s	+2.3%
index_join_postgres	668.98/s	674.58/s	+0.8%
index_join_scan_postgres	849.39/s	849.00/s	-0.1%
index_scan_postgres	31.28/s	31.59/s	+0.9%
oltp_delete_insert_postgres	821.09/s	792.60/s	-3.5%
oltp_insert	736.61/s	689.78/s	-6.4%
oltp_point_select	3540.12/s	3567.29/s	+0.7%
oltp_read_only	3498.29/s	3490.21/s	-0.3%
oltp_read_write	2641.20/s	2614.12/s	-1.1%
oltp_update_index	777.20/s	714.69/s	-8.1%
oltp_update_non_index	788.43/s	834.23/s	+5.8%
oltp_write_only	1647.57/s	${\color{lightgreen}1841.43/s}$	${\color{lightgreen}+11.7\%}$
select_random_points	2162.65/s	2178.67/s	+0.7%
select_random_ranges	1597.22/s	1589.15/s	-0.6%
table_scan_postgres	30.97/s	30.92/s	-0.2%
types_delete_insert_postgres	750.05/s	${\color{lightgreen}832.33/s}$	${\color{lightgreen}+10.9\%}$
types_table_scan_postgres	14.05/s	13.87/s	-1.3%

[itoqa]

Commit: f8ec773: 16 test cases ran, 11 passed ✅, 5 additional findings ⚠️.

Summary

Coverage spans core build and startup behavior, basic SQL execution, reconnect and persistence flows, branch isolation, concurrent changes, data-type handling, and recovery from malformed or oversized inputs. It also exercises broader compatibility and edge-case behavior around prepared statements, array operations, nulls, conversions, and branch-summary queries.

Safe to merge — the failures identify pre-existing product limitations and unrelated database behavior, while this dependency-only change introduced no regressions or new PR-attributable failures. The unrelated findings should be addressed separately, but they are not merge blockers for this pull request.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Build	The upgraded dependencies compiled into a Doltgres executable, the local server started, and a basic SQL query returned 1. The repository build wrapper needed a Docker-host workaround because Docker was not available inside the nested test container.
✅	—	Build	The dependency set resolved, the application compiled, and a basic SQL query returned 1. The planned incompatible-dependency failure could not be exercised because the test supplied no incompatible dependency change or fixture.
✅	—	Startup	A fresh local server accepted a PostgreSQL connection, created a table, inserted one row, and returned the expected value 1:ready.
✅	—	Startup	Two sessions opened during startup and immediate reconnects returned the expected database and array-type values. The results stayed consistent instead of changing with request timing.
✅	—	Storage	The committed tables, rows, and foreign-key links were still available after a fresh connection.
✅	—	Storage	The feature branch kept the committed root and its feature row, while the main branch kept the committed root and its working row. Switching branches did not mix or lose data.
✅	—	Storage	Two sessions committed separate table and foreign-key changes at the same time. After reconnecting, both tables, both rows, and both foreign keys were still present.
✅	—	Wire	Exact scalar values and binary array and record values were decoded correctly, with the reader staying at the expected position.
✅	—	Wire	A near-maximum byte length after a valid prefix was rejected with the correct offset and remaining-byte message.
✅	—	Wire	A malformed binary request returned a clear error, while another session returned 42 and a reconnected session returned 7.
✅	—	Wire	A malformed nested value returned a bounded error, and the same session then returned 99 and {1,2} correctly.
⚠️		Engine	The server rejects a prepared query and cannot run the required array filter, so the full SQL value workflow does not complete.
⚠️		Engine	The null expressions returned the expected null values, and invalid numeric conversions returned bounded errors while the connection stayed usable. The prepared null query failed because PREPARE and EXECUTE are unsupported, and the integer-array equality query failed with 'operator does not exist: integer[] = integer[]' instead of returning true.
⚠️		Engine	The domain cast, composite predicate, scalar-array predicate, null handling, metadata, and fresh-session results match as expected. The prepared expression fails with an unsupported-feature error during PREPARE, and EXECUTE is also unsupported, so the required prepared form cannot run.
⚠️		Startup	A prepared query returns an unsupported error, so the query never runs and no result is returned.
⚠️		Storage	The required branch state checks passed: fresh connections returned committed,working-main on main and committed,branch-committed on the branch. However, the additional branch-listing query SELECT 'branches=' || string_agg(name, ',' ORDER BY name) FROM dolt_branches failed with unable to find field with index 13 in row of 1 columns, followed by the server's This is a bug diagnostic.

Additional Findings Details

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

🟠 Prepared queries and array filters fail

• Severity: High
• Description: The server rejects a prepared query and cannot run the required array filter, so the full SQL value workflow does not complete.
• Impact: Applications that use prepared queries or text-array filters cannot complete those database operations. Affected SQL workflows fail, although other scalar and custom-value operations still work.
• Steps to Reproduce:
  1. Connect to the local SQL server as the postgres user.
  2. Create a table with a text[] column and insert a row such as ARRAY['a','b'].
  3. Run valid scalar, array, composite, enum, and domain literals; these succeed.
  4. Run PREPARE with an integer parameter and then EXECUTE it; the server returns that PREPARE is not supported.
  5. Run a query with a condition such as tags @> ARRAY['a']::text[]; the server reports that the text[] containment operator does not exist.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The PREPARE failure is deterministic in repo/server/ast/prepare.go:23-29. nodePrepare is the AST conversion handler for tree.Prepare nodes, and after the nil guard it unconditionally returns NotYetSupportedError("PREPARE is not yet supported") without producing a statement. repo/server/ast/convert.go:185 routes parsed PREPARE statements into nodePrepare, so every ordinary SQL PREPARE request reaches this rejection. The array failure is also consistent with the production expression path. repo/server/ast/expr.go:444-448 translates tree.Contains, which is the parsed form of @>, into framework.Operator_BinaryJSONContainsRight. repo/server/functions/framework/operators.go:269-270 maps the @> token to that JSON-specific operator, and repo/server/functions/binary/json.go:73 registers its JSONB implementation. There is no corresponding text[] containment implementation in these paths, so a text[] @> text[] expression cannot resolve to a matching operator. The PR context shows only dependency-version and checksum edits in go.mod and go.sum; none of these production files or their behavior is changed by the PR.

Evidence Package

• text/ENGINE-1/ENGINE-1-sql-reproduction.txt — 3 KB

🟡 Prepared nulls and array comparisons fail

• Severity: Medium
• Description: The null expressions returned the expected null values, and invalid numeric conversions returned bounded errors while the connection stayed usable. The prepared null query failed because PREPARE and EXECUTE are unsupported, and the integer-array equality query failed with 'operator does not exist: integer[] = integer[]' instead of returning true.
• Impact: Applications cannot use prepared statements or compare integer arrays because those queries fail instead of running. Null handling and other scalar queries continue to work.
• Steps to Reproduce:
  1. Connect to the local database and run SELECT NULL::integer, SELECT NULL::text[], and a null domain expression.
  2. Run PREPARE qa_engine2_null AS SELECT NULL::integer, then run EXECUTE qa_engine2_null.
  3. Run SELECT 40000::smallint and SELECT 'not-an-int'::integer, then run a valid scalar query followed by SELECT ARRAY[1,2] = ARRAY[1,2].
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The prepared-query failure is deterministic in the production conversion path. server/ast/convert.go dispatches *tree.Prepare and *tree.Execute nodes to nodePrepare and nodeExecute at lines 166-167 and 193-194. server/ast/prepare.go:23-30 returns NotYetSupportedError("PREPARE is not yet supported") for every non-nil PREPARE node, while server/ast/execute.go:23-29 does the same for every EXECUTE node. This directly explains both preparation errors and the later prepared-statement-does-not-exist message. The array comparison failure is also code-backed: server/expression/binary_operator.go:146-150 asks framework.GetBinaryFunction(b.operator).Compile for the two array operands and returns operator-not-found when compilation returns nil. server/functions/framework/operators.go:249-251 maps '=' to the generic binary equality function, but does not provide an array-specific equality implementation; the unresolved integer[] operands match the observed error. The conversion errors themselves are bounded and the follow-up scalar query succeeds, so session recovery is not the defect being reported.

Evidence Package

• text/ENGINE-2/ENGINE-2-sql-evidence.txt — 2 KB

🟡 Prepared expressions fail for valid values

• Severity: Medium
• Description: The domain cast, composite predicate, scalar-array predicate, null handling, metadata, and fresh-session results match as expected. The prepared expression fails with an unsupported-feature error during PREPARE, and EXECUTE is also unsupported, so the required prepared form cannot run.
• Impact: Users cannot run valid prepared SQL statements, so applications that rely on parameterized queries must use a different query form or avoid this feature.
• Steps to Reproduce:
  1. Create a domain, array, and composite type, and prepare a query that uses one of them as a parameter.
  2. Execute the prepared query in the existing session.
  3. Repeat the metadata, cast, predicate, and null checks in a fresh session and compare the results.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime evidence is supported by the production SQL conversion path. server/ast/convert.go:184-185 dispatches parsed PREPARE statements to nodePrepare. In server/ast/prepare.go:23-30, nodePrepare returns NotYetSupportedError("PREPARE is not yet supported") for every non-nil PREPARE node; it does not analyze, bind, or execute the contained statement. The follow-up path is independently blocked in server/ast/execute.go:25-29, where nodeExecute returns NotYetSupportedError("EXECUTE is not yet supported"). This explains both observed errors and why literal expressions can succeed while the parameterized form cannot. The smallest practical fix is to implement the existing PREPARE and EXECUTE AST handlers through the connection's prepared-statement machinery, preserving parameter type resolution and execution; until then, the unsupported errors should not be treated as successful analyzer/conversion coverage. The PR context shows only version replacements in go.mod and go.sum, at go.mod lines 9 and 12 for the Dolt and go-mysql-server modules, with no changes to these handlers.

Evidence Package

• text/ENGINE-3/prepared-expression-evidence.txt — 3 KB

🟡 Prepared queries are not supported

• Severity: Medium
• Description: A prepared query returns an unsupported error, so the query never runs and no result is returned.
• Impact: Applications that use prepared queries receive an unsupported error and cannot run those queries. Other query modes and reconnects continue to work, so affected clients may use direct queries as a workaround.
• Steps to Reproduce:
  1. Connect to a fresh local Doltgres instance as the postgres user.
  2. Run PREPARE qa_scalar(int) AS SELECT $1 + 10;.
  3. Run EXECUTE qa_scalar(32);.
  4. Observe that both statements return a not-yet-supported error instead of creating and running the prepared statement.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The parser produces tree.Prepare and tree.Execute nodes, and the server dispatches those nodes to nodePrepare and nodeExecute. In server/ast/prepare.go:23-30, nodePrepare returns NotYetSupportedError("PREPARE is not yet supported") for every non-nil PREPARE node. In server/ast/execute.go:23-30, nodeExecute likewise returns NotYetSupportedError("EXECUTE is not yet supported") for every non-nil EXECUTE node. These unconditional returns are a direct production-code explanation for the observed PREPARE and EXECUTE errors; the malformed cast and later scalar/array queries recovering successfully show that the failure is specific to prepared statements rather than a general connection or reconnect failure. The smallest product fix is to implement the existing PREPARE and EXECUTE AST handlers using the server's prepared-statement execution path, or to make the supported-client contract explicitly reject this mode before clients depend on it; the current behavior cannot satisfy the test's required compatibility.

Evidence Package

• text/STARTUP-3/prepared-query-failure.txt — 2 KB

🟡 Listing branches with a summary query crashes

• Severity: Medium
• Description: The required branch state checks passed: fresh connections returned committed,working-main on main and committed,branch-committed on the branch. However, the additional branch-listing query SELECT 'branches=' || string_agg(name, ',' ORDER BY name) FROM dolt_branches failed with unable to find field with index 13 in row of 1 columns, followed by the server's This is a bug diagnostic.
• Impact: Users cannot use this supported branch-listing query pattern to build a single comma-separated result. They can work around it by reading branch rows individually and combining them outside the database.
• Steps to Reproduce:
  1. Create a local database and add a committed row, a working row, and a branch-specific committed row.
  2. Switch back to the main branch after checking the branch contents.
  3. Run SELECT 'branches=' || string_agg(name, ',' ORDER BY name) FROM dolt_branches;.
  4. Observe the server error instead of a single aggregated branch-name result.
• Stub / mock content: The test used a local Doltgres database with test tables and rows created for the run. No production data, route mocks, or application-code bypasses were used.
• Code Analysis: The repository explicitly registers the Dolt branches system-table name through doltdb.GetBranchesTableName = getBranchesTableName in server/tables/dtables/init.go:26-33, and getBranchesTableName returns branches at lines 66-69. The repository's own system-table coverage treats dolt_branches as a supported relation and verifies direct projections such as SELECT name FROM dolt_branches and SELECT dolt_branches.name FROM dolt_branches in testing/go/dolt_tables_test.go:34-55. The recorded query uses that supported relation but fails during aggregation with an internal field-index lookup for index 13 in a one-column row, which is consistent with a server execution or row-schema handling defect rather than invalid SQL. The PR diff changes only dependency versions in go.mod and go.sum; no local implementation change explains or directly fixes this path. The smallest practical fix is to correct the system-table row schema/field lookup used by aggregate expressions over dolt_branches, then add this exact aggregate query as a regression test.

Evidence Package

• text/STORAGE-4/STORAGE-4-branch-state-and-query.txt — 2 KB

Tip

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

[github-actions]

This PR has been superseded by #3076