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

[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	18406	18407
Failures	23684	23683
Partial Successes1	5327	5327

	Main	PR
Successful	43.7301%	43.7325%
Failures	56.2699%	56.2675%

${\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: 8d1c891: 21 test cases ran, 15 passed ✅, 6 additional findings ⚠️.

Summary

Coverage spans core database behavior including connections, isolated sessions, transactions, schema changes and recovery, persistence across reconnects and merges, historical reads, indexing, typed data, generated identifiers, bounded and recreated sequences, common type handling, and error recovery. It also exercises compatibility and edge cases such as invalid inputs, unsupported prepared queries, sequence exhaustion, and large JSON numeric precision, with ordinary data operations broadly healthy.

Safe to merge — no observed failure is attributable to this PR, which changes only dependency versions and shows no regression or new PR-related failure. Existing medium-severity compatibility and data-precision limitations remain flag-for-later issues rather than merge blockers.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Engine	Creating, changing, renaming, querying, and dropping a table all worked. The renamed table returned the saved row with its updated value, and the dropped table was absent afterward.
✅	—	Engine	A duplicate-column change failed without altering the table. After reconnecting, the intended column was added and new and existing rows stayed correct.
✅	—	Sequence	Two database sessions inserted 100 rows, and every generated identifier was unique from 1 through 100.
✅	—	Sequence	Positive and negative non-cycling sequences returned only values inside their configured bounds, then reported the correct maximum and minimum exhaustion errors.
✅	—	Sequence	After the sequence was dropped and recreated, both sessions found the new sequence and returned 100 and 101.
✅	—	Sequence	Concurrent inserts created 121 rows with 121 unique IDs, and a reconnected client received the next ID, 121. The later sequence-state check could not run again because the local test service had stopped.
✅	—	Server	The server accepted valid credentials, created a test table, saved one row, and returned that row successfully.
✅	—	Server	Concurrent sessions returned the correct data from each database, and reconnecting kept the expected table visible.
✅	—	Server	The committed row was still present after reconnecting, and the later committed update was also visible with the same row ID.
✅	—	Storage	The table kept its schema and all three rows after commits, a branch merge, and a fresh database connection.
✅	—	Storage	The current query returned both committed rows, while the historical query returned only the row from the first commit.
✅	—	Storage	Indexed filtering returned the expected rows, a wrapped query returned the expected rows, and the updated score remained visible after the mutation was committed.
✅	—	Storage	After reconnecting, the typed rows, column types, indexes, and later update were all still correct.
✅	—	Types	Integer and bigint expressions resolve to bigint, mixed numeric expressions resolve to numeric, and domain equality plus both implicit cast directions return the expected results.
✅	—	Types	After an unsupported sequence value was tried, later valid sequence calls and follow-up queries continued to work. The later rerun was blocked by the unavailable local target, and source review did not confirm a product defect.
⚠️		Engine	The database rejects the required parameterized PREPARE statement before the prepared query can be executed.
⚠️		Sequence	The invalid create and setval calls return errors as expected, and later nextval/setval calls recover with values 10, 20, and 21. The required current-value query then fails with a function-not-found error; it should return the value produced by the preceding nextval call.
⚠️		Server	The server rejects the prepared statement instead of creating it, even though authentication succeeds.
⚠️		Server	The timestamp formatting checks pass for literal queries, DateStyle changes, RESET, and a fresh session. The prepared timestamp query fails immediately with an unsupported-operation error, so the full compatibility workflow cannot complete.
⚠️		Types	The invalid array and cast statements produced controlled errors, and a later valid query returned the expected values. The required PREPARE and EXECUTE commands returned 'not yet supported' errors, so the parameterized SQL query never ran.
⚠️		Types	The requested JSON integer 9007199254740993 was returned as 9007199254740992. This changes the value without an error, while the tested timestamps, arrays, NULL placement, and composite field order remained stable.

Additional Findings Details

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

🟡 Parameterized SQL statements cannot run

• Severity: Medium
• Description: The database rejects the required parameterized PREPARE statement before the prepared query can be executed.
• Impact: Users who rely on parameterized SQL queries cannot prepare or execute them. Other basic database operations still work, and users can avoid the issue by sending values directly in SQL.
• Steps to Reproduce:
  1. Connect to a local database and create a table with a few rows.
  2. Run ordinary INSERT, UPDATE, DELETE, SELECT, and aggregate queries inside a transaction; these operations complete successfully.
  3. Run a parameterized PREPARE statement and then try to execute it with a value.
  4. Observe that the PREPARE command fails with 'PREPARE is not yet supported'.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The parser has a tree.Prepare node and routes it to server/ast/nodePrepare. In server/ast/prepare.go:24-29, nodePrepare returns nil only for a nil node; for every real PREPARE statement it immediately returns NotYetSupportedError("PREPARE is not yet supported"). The implementation does not build a prepared plan, bind parameter types, or hand the query to the executor. server/ast/execute.go likewise rejects EXECUTE, so the failure is a complete production-code gap rather than a transient client error. The run's successful transaction, mutation, filtered SELECT, and aggregate output shows that the database connection and ordinary SQL execution were working. The smallest practical fix is to implement the existing PREPARE and EXECUTE AST paths using the server's prepared-statement support, or explicitly remove this test requirement if prepared statements are intentionally unsupported; changing dependency versions alone does not address the current handler.

Evidence Package

• text/ENGINE-1/ENGINE-1-prepared-statement-failure.txt — 2 KB

🟡 Sequence recovery cannot read current value

• Severity: Medium
• Description: The invalid create and setval calls return errors as expected, and later nextval/setval calls recover with values 10, 20, and 21. The required current-value query then fails with a function-not-found error; it should return the value produced by the preceding nextval call.
• Impact: Users who rely on the database's current sequence value cannot complete that sequence workflow because the required function is unavailable. Other sequence operations still work, and there is no evidence of data loss or corruption.
• Steps to Reproduce:
  1. Create a sequence named seq3 with a starting value of 10.
  2. Attempt to create seq3 again and call setval with the text value unsupported; confirm both invalid operations return controlled errors.
  3. In the same session, call nextval('seq3'), then currval('seq3'), then setval('seq3', 20) and nextval('seq3').
  4. Observe that nextval returns 10 and later 21, while currval fails with function 'currval' not found instead of returning the current sequence value.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime result is backed by the production catalog implementation. In server/functions/nextval.go, initNextVal at lines 30-34 registers only nextval_text and nextval_regclass. In server/functions/setval.go, initSetVal at lines 36-40 registers only the two setval overloads. A repository-wide search finds currval in optimizer handling at server/analyzer/optimize_functions.go:55 and :100, PostgreSQL regression tests such as testing/go/regression/tests/sequence.sql:117-118 and :323-348, and built-in function metadata at core/id/cache_function_defaults.go:957, but there is no currval implementation or framework.RegisterFunction(currval...) call. The missing registration therefore deterministically produces the observed function-not-found error independent of the test environment. The smallest practical fix is to implement the session-aware currval behavior using the existing sequence tracker/state and register the text and regclass overloads required by the existing regression coverage; this should be a targeted addition to the sequence functions rather than a broad sequence rewrite.

Evidence Package

• text/SEQUENCE-3/recovery-currval-failure.txt — 2 KB

🟡 Prepared statements are not supported

• Severity: Medium
• Description: The server rejects the prepared statement instead of creating it, even though authentication succeeds.
• Impact: Applications that use prepared queries cannot complete those database operations. Ordinary connections and login checks still work.
• Steps to Reproduce:
  1. Connect to the local server with valid PostgreSQL credentials and TLS disabled.
  2. Run PREPARE compat_stmt(text) AS SELECT $1 || '-ok';.
  3. Observe the error: PREPARE is not yet supported.
  4. Confirm that a normal authenticated connection still works and that wrong-password and wrong-database attempts are rejected.
• Stub / mock content: A local isolated database and local development credentials were used; no application stubs, mocks, route interception, or bypasses were applied for this test.
• Code Analysis: The parser creates a tree.Prepare node for PREPARE statements, but server/ast/prepare.go:23-30 handles that node by returning NotYetSupportedError("PREPARE is not yet supported") for every non-nil statement. There is no statement registration, planning, or execution path after this return, so the failure is deterministic and affects every client that sends a SQL PREPARE command. The PR context contains only version changes for github.com/dolthub/dolt/go and github.com/dolthub/go-mysql-server in go.mod plus corresponding checksums in go.sum; it does not modify this handler or provide a changed-code path that causes the rejection. The smallest practical fix is to implement the existing tree.Prepare path through statement storage and execution, or explicitly gate/document the unsupported capability for clients; changing dependency versions alone will not address this handler.

Evidence Package

• text/SERVER-3/SERVER-3-prepared-statement-failure.txt — 2 KB

🟡 Prepared timestamp queries are rejected

• Severity: Medium
• Description: The timestamp formatting checks pass for literal queries, DateStyle changes, RESET, and a fresh session. The prepared timestamp query fails immediately with an unsupported-operation error, so the full compatibility workflow cannot complete.
• Impact: Applications that use prepared timestamp queries receive an unsupported-operation error instead of a timestamp, so those database workflows cannot complete. Literal timestamp queries still work.
• Steps to Reproduce:
  1. Connect to the local database and run a literal timestamp query.
  2. Set DateStyle to SQL, DMY and run the same literal timestamp query; it returns the expected formatted value.
  3. Run PREPARE ts_stmt AS SELECT TIMESTAMP '2026-08-12 13:14:15'.
  4. Observe the error that PREPARE is not yet supported, then reset DateStyle and confirm that literal queries still work.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime evidence is reproduced by the production source. In server/ast/prepare.go, nodePrepare handles parsed tree.Prepare nodes and returns NotYetSupportedError("PREPARE is not yet supported") at lines 23-30 for every non-nil PREPARE node; there is no execution path for the prepared timestamp query. The separate DateStyle path in server/config/parameters.go lines 216-224 clears the cached date output format before applying a session value, which matches the observed literal-query behavior and rules out stale DateStyle formatting as the cause. The PR context shows only dependency-version and checksum edits in go.mod and go.sum, so no changed application line can be tied directly to this failure. The smallest practical fix is to implement the required PREPARE/EXECUTE handling for this query path, or explicitly add the missing supported case in the existing prepare handler rather than changing the DateStyle cache logic.

Evidence Package

• text/SERVER-5/SERVER-5-prepared-timestamp-evidence.txt — 2 KB

🟡 Prepared SQL statements are unsupported

• Severity: Medium
• Description: The invalid array and cast statements produced controlled errors, and a later valid query returned the expected values. The required PREPARE and EXECUTE commands returned 'not yet supported' errors, so the parameterized SQL query never ran.
• Impact: Clients and migration tools that use SQL PREPARE and EXECUTE cannot run parameterized queries. Other queries still work, and users may use a direct query or a supported protocol path instead.
• Steps to Reproduce:
  1. Open a local database session and run a malformed ANY expression, such as 2 = ANY(ARRAY['1','bad']::integer[]).
  2. Run an invalid cast, such as SELECT 'not-an-int'::integer, and allow the session to continue after the error.
  3. Run a valid comparison and cast to confirm the session still works.
  4. Run PREPARE types_recovery(integer) AS SELECT $1 + 10, then run EXECUTE types_recovery(5).
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run. The test used an isolated local database and standard SQL commands.
• Code Analysis: The production path directly confirms the failure. In server/ast/prepare.go, nodePrepare at lines 23-30 handles parsed tree.Prepare nodes and unconditionally returns NotYetSupportedError("PREPARE is not yet supported") at line 29; it does not create or register a prepared SQL statement. The runtime output matches this exact error, and EXECUTE consequently cannot find a usable SQL-prepared statement and is also rejected. The repository does have a different feature in server/connection_handler.go:653-725: handleParse processes PostgreSQL wire Parse messages, analyzes the query, stores PreparedStatementData, and sends ParseComplete. That protocol path is not equivalent to the SQL PREPARE/EXECUTE grammar exercised here and does not satisfy the explicit SQL capability requirement. The smallest practical fix is to implement the existing tree.Prepare path using the server's prepared-statement registration and execution machinery, or explicitly route SQL PREPARE/EXECUTE through that machinery; this does not require changing the array or cast recovery paths. The PR diff contains only go.mod and go.sum dependency-version updates, with no changed lines in either relevant server file, so causation by this PR is unproven and is classified as False.

Evidence Package

• text/TYPES-2/TYPES-2-sql-recovery.txt — 2 KB
• text/TYPES-2/TYPES-2-source-path.txt — 987 B

🟡 Large JSON numbers lose precision

• Severity: Medium
• Description: The requested JSON integer 9007199254740993 was returned as 9007199254740992. This changes the value without an error, while the tested timestamps, arrays, NULL placement, and composite field order remained stable.
• Impact: Users may receive a large JSON number with its value silently changed. This can cause incorrect results when their data contains integers beyond the supported precision range.
• Steps to Reproduce:
  1. Send a JSON value containing the integer 9007199254740993 through the database JSON input path.
  2. Read the JSON value back through a PostgreSQL client.
  3. Compare the returned number with the original input.
  4. Observe that the database returns 9007199254740992 instead of 9007199254740993.
• Stub / mock content: An isolated local database and PostgreSQL client were used for this test. No stubs, mocks, route interceptions, or bypasses were applied.
• Code Analysis: The runtime evidence is consistent with the production JSON input path. In server/functions/json.go, json_in_callable (lines 58-69) calls goccy/go-json.Unmarshal into an untyped interface and stores the resulting value in types.JSONDocument. Unlike server/types/json_document.go's UnmarshalToJsonDocument (lines 232-245), this path does not call Decoder.UseNumber(), so numeric tokens are decoded through the generic float64 representation. ConvertToJsonDocument in server/types/json_document.go then handles float64 at lines 314-321 and includes a TODO stating that float64 is not precise enough before scanning it into an apd.Decimal. The input 9007199254740993 is therefore rounded to the nearest representable float before it is formatted back to JSON, matching the observed 9007199254740992. The smallest practical fix is to make json_in_callable use the number-preserving decoder/path already present in UnmarshalToJsonDocument, or otherwise configure its decoder with UseNumber before constructing the JSON document. The PR context shows only dependency-version edits in go.mod and go.sum, with no changed lines in this path, so this is not a PR-introduced regression.

Evidence Package

• text/TYPES-3/TYPES-3-json-precision.txt — 2 KB

Tip

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

[github-actions]

	Main	PR
covering_index_scan_postgres	2201.58/s	2218.63/s	+0.7%
groupby_scan_postgres	158.70/s	158.48/s	-0.2%
index_join_postgres	712.89/s	714.05/s	+0.1%
index_join_scan_postgres	928.18/s	938.29/s	+1.0%
index_scan_postgres	33.78/s	33.92/s	+0.4%
oltp_delete_insert_postgres	952.79/s	904.53/s	-5.1%
oltp_insert	842.24/s	842.85/s	0.0%
oltp_point_select	3953.04/s	3890.87/s	-1.6%
oltp_read_only	3742.57/s	3758.10/s	+0.4%
oltp_read_write	2789.30/s	2749.58/s	-1.5%
oltp_update_index	880.52/s	861.62/s	-2.2%
oltp_update_non_index	939.97/s	944.10/s	+0.4%
oltp_write_only	1981.97/s	1992.12/s	+0.5%
select_random_points	2299.68/s	2289.69/s	-0.5%
select_random_ranges	1707.49/s	1716.53/s	+0.5%
table_scan_postgres	33.39/s	33.44/s	+0.1%
types_delete_insert_postgres	925.10/s	918.05/s	-0.8%
types_table_scan_postgres	14.83/s	14.81/s	-0.2%