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

[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	18951	18947
Failures	23139	23143
Partial Successes1	5340	5336

	Main	PR
Successful	45.0249%	45.0154%
Failures	54.9751%	54.9846%

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	2067.24/s	2087.10/s	+0.9%
groupby_scan_postgres	152.58/s	153.55/s	+0.6%
index_join_postgres	675.97/s	667.30/s	-1.3%
index_join_scan_postgres	845.47/s	847.02/s	+0.1%
index_scan_postgres	31.73/s	31.85/s	+0.3%
oltp_delete_insert_postgres	793.37/s	789.95/s	-0.5%
oltp_insert	735.25/s	726.70/s	-1.2%
oltp_point_select	3480.96/s	3534.59/s	+1.5%
oltp_read_only	3458.15/s	3529.15/s	+2.0%
oltp_read_write	2615.87/s	2606.27/s	-0.4%
oltp_update_index	756.93/s	737.45/s	-2.6%
oltp_update_non_index	800.17/s	794.98/s	-0.7%
oltp_write_only	1841.22/s	1831.16/s	-0.6%
select_random_points	2166.20/s	2189.93/s	+1.0%
select_random_ranges	1609.76/s	1662.95/s	+3.3%
table_scan_postgres	31.15/s	31.28/s	+0.4%
types_delete_insert_postgres	827.23/s	817.32/s	-1.2%
types_table_scan_postgres	13.95/s	14.21/s	+1.8%

[itoqa]

Commit: 64f87b4: 13 test cases ran, 9 passed ✅, 4 additional findings ⚠️.

Summary

Coverage spans clean and repeatable builds, server startup and restart persistence, concurrent database sessions, table and relationship changes, mixed-type query behavior, and JSON handling. It includes happy-path workflows plus edge cases around type consistency, escaped keys, malformed paths, large numeric values, and state surviving restarts; core application behavior exercised by the change remains healthy.

Safe to merge — the dependency-only change shows no regressions or failures attributable to this PR, and the build, database workflows, persistence, and concurrency checks pass. Several pre-existing medium-to-high severity compatibility gaps remain in mixed numeric set operations and JSONPath/large-number handling, but they are unrelated flag-for-later findings rather than merge blockers.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Build	The project compiled successfully from an empty Go module cache, and the full test suite passed. The expected Dolt, go-mysql-server, and jsonpath versions resolved correctly.
✅	—	Build	The compiled server started successfully and completed mixed-type SQL, JSON value extraction, table creation, commit, branch creation, and fresh-session readback. The database listener is PostgreSQL-only, so the browser could not load it as an HTTP page, but the required database checks passed through a PostgreSQL client.
✅	—	Build	The server built with an empty dependency cache and with a warmed cache produced identical binaries. Both builds started successfully and completed the same SQL, JSON, table, commit, and branch checks.
✅	—	Execution	Fresh and warmed sessions returned the same values, result type, and no errors for the mixed query.
✅	—	Startup	A clean server start created the default database before the first connection. The first normal session created a table, inserted a row, and read it back successfully.
✅	—	Startup	The saved startup_state row was still available after restart. The qa.startup value was session-only, so expecting it in a new connection was a test setup mistake rather than a product failure.
✅	—	Startup	Eight rapid sessions before restart and eight sessions after restart each found the expected database and startup row without partial-state errors.
✅	—	Storage	The renamed staff table and Ada's updated department were still present after the database restarted. The old employees table name was gone.
✅	—	Storage	The foreign key still points to the renamed parent table after the repository was reloaded, and a valid child row was inserted successfully.
⚠️		Jsonpath	The large number came back as 9007199254740992 instead of 9007199254740993 after restart. The JSONPath query also returned a function-not-found error, so the path operation could not run; ordinary field lookup still returned the expected value.
⚠️		Execution	Mixed numeric UNION queries returned text values instead of bigint for int plus bigint and numeric for numeric plus int.
⚠️		Jsonpath	Direct key extraction returns the expected values, but the path query fails with a function-not-found error. The expected result is a JSON value from the selected key, including keys with escaped quotes or dots in their names.
⚠️		Jsonpath	The malformed JSONPath statement reports that jsonb_path_query_first is not found. The later ordinary JSONB read returns v2 and null in both sessions, but the required valid JSONPath follow-up cannot run, so the feature cannot isolate malformed errors or recover across sessions.

Additional Findings Details

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

🟠 JSON data loses precision and queries are unavailable

• Severity: High
• Description: The large number came back as 9007199254740992 instead of 9007199254740993 after restart. The JSONPath query also returned a function-not-found error, so the path operation could not run; ordinary field lookup still returned the expected value.
• Impact: Users cannot query stored JSON by path, and some large numbers silently change after a restart. Applications may then use the wrong identifier or measurement, with no error to warn them.
• Steps to Reproduce:
  1. Insert a JSONB row containing the number 9007199254740993, an array, and a nested null value.
  2. Restart the local database server and select the stored row again.
  3. Compare the returned large number with the inserted value, then run jsonb_path_query_first on the row with a malformed path such as $.bad[.
  4. Run a normal JSONB field lookup after the error to check whether later reads still work.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production JSONB function package registers only jsonb_in, jsonb_out, jsonb_recv, jsonb_send, jsonb_cmp, jsonb_build_array, and jsonb_build_object in server/functions/jsonb.go:28-37. There is no executable registration or callable implementation for jsonb_path_query, jsonb_path_query_first, or jsonb_path_exists anywhere in the server/functions package, even though core/id/cache_function_defaults.go:2730-2733 contains catalog metadata naming those functions. The catalog metadata therefore advertises function IDs but cannot make the SQL calls executable, matching the recorded function-not-found error and the regression calls in testing/go/regression/tests/jsonb_jsonpath.sql:21-26 and :42-57. JSON output does unwrap stored values and formats JSON wrappers in server/functions/json.go:80-104 and server/functions/json.go:115-141, while jsonb_send serializes the SQL value in server/functions/jsonb.go:76-100; those paths explain why arrays and nulls can survive the restart but do not provide JSONPath evaluation or guarantee exact handling of values beyond the numeric representation used by the underlying JSON document conversion. The observed 9007199254740993 to 9007199254740992 change is silent data corruption for that value, not merely a formatting difference. The smallest practical fixes are to implement and register the required JSONPath functions, and to preserve JSON numeric literals without converting unsafe integers through a lossy floating-point representation during JSONB parsing, persistence, or output.

Evidence Package

• text/JSONPATH-2/JSONPATH-2-restart-readback.txt — 3 KB

🟡 Mixed numeric UNION results become text

• Severity: Medium
• Description: Mixed numeric UNION queries returned text values instead of bigint for int plus bigint and numeric for numeric plus int.
• Impact: Mixed numeric UNION queries can return text instead of numeric values. Users may see broken calculations or client code errors when those results are expected to be numeric.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL-compatible server in a fresh session.
  2. Run SELECT x, pg_typeof(x) FROM (SELECT 1::int AS x UNION ALL SELECT 2::bigint) AS u; and inspect the reported type.
  3. Run SELECT x, pg_typeof(x) FROM (SELECT 1::numeric AS x UNION ALL SELECT 2::int) AS u; and inspect the reported type.
  4. Compare the UNION results with mixed VALUES expressions, which should resolve the first case to bigint and the second case to numeric.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production path in server/ast/union_clause.go:26-68 converts the left and right SELECT nodes and returns a vitess.SetOp containing only the operator and child nodes. It does not inspect the result schemas, call framework.FindCommonType, or insert implicit casts before the set operation is executed. The missing behavior is especially clear because server/analyzer/resolve_values_types.go:33-35 documents PostgreSQL-compatible common-type selection, and transformValuesNode at lines 202-223 already calls framework.FindCommonType and wraps expressions with pgexprs.NewImplicitCast when a mixed VALUES column needs casts. That analyzer rule is registered at server/analyzer/init.go:67-74 as ResolveValuesTypes, but its implementation only handles plan.Values and plan.ValueDerivedTable nodes at resolve_values_types.go:157-169, not UNION SetOp nodes. The shared helper in server/functions/framework/common_type.go:29-95 is capable of selecting a common type and validating implicit casts, so the failure is an uncovered UNION/set-operation path rather than an absent type-resolution capability. The smallest practical fix is to apply the same common-type and cast insertion logic to each compatible UNION output column before constructing or executing the SetOp, while preserving an error for genuinely incompatible categories.

Evidence Package

• text/EXECUTION-1/mixed-union-type-resolution.txt — 2 KB
• text/EXECUTION-1/union-source-path.txt — 2 KB

🟡 Escaped JSON keys cannot use path queries

• Severity: Medium
• Description: Direct key extraction returns the expected values, but the path query fails with a function-not-found error. The expected result is a JSON value from the selected key, including keys with escaped quotes or dots in their names.
• Impact: Users who rely on JSONPath queries cannot read values from escaped or path-like JSON keys. Basic direct key extraction still works, but there is no normal workaround for workflows that require path-based queries.
• Steps to Reproduce:
  1. Connect to the local SQL server and create a table with a JSONB column.
  2. Insert an object containing an escaped-quote key such as escaped"key and a dotted key such as a.b.
  3. Read the values with direct JSONB field extraction and confirm they are v1 and v2.
  4. Run a JSONPath query that reads the same object, such as jsonb_path_query_first(payload, '$.a.b').
  5. Observe the function-not-found error instead of a JSONPath result.
• Stub / mock content: A local JSONB table and deterministic fixture object were used; no application mocks, route interception, or bypasses were applied.
• Code Analysis: The runtime evidence reports function: 'jsonb_path_query_first' not found after direct extraction of the escaped and dotted keys succeeds. The production registration file server/functions/jsonb.go:28-38 registers only jsonb_in, jsonb_out, jsonb_recv, jsonb_send, jsonb_cmp, jsonb_build_array, and jsonb_build_object; it has no JSONPath query registrations. The implementation file server/functions/json.go:39-47 likewise registers JSON I/O and build functions only, and its output/send code handles serialization rather than path evaluation. core/id/cache_function_defaults.go:2726-2736 contains catalog metadata names for jsonpath I/O and jsonb_path_exists/jsonb_path_query/jsonb_path_query_first, but those setBuiltIn entries do not create callable implementations or framework registrations. The regression SQL at testing/go/regression/tests/jsonb_jsonpath.sql:21-26 expects JSONPath operations, so catalog names without executable functions leave the tested feature unavailable. The smallest practical fix is to add the missing JSONPath function implementation and register at least the functions required by this query, using the existing JSONPath dependency and preserving exact-key semantics; the broader timezone and operator variants should be added only as required by their own coverage.

Evidence Package

• text/JSONPATH-1/JSONPATH-1-jsonpath-query-failure.txt — 3 KB

🟡 Malformed JSONPath breaks required query support

• Severity: Medium
• Description: The malformed JSONPath statement reports that jsonb_path_query_first is not found. The later ordinary JSONB read returns v2 and null in both sessions, but the required valid JSONPath follow-up cannot run, so the feature cannot isolate malformed errors or recover across sessions.
• Impact: Applications that use JSONPath queries cannot run those queries, including valid lookups after a malformed query. They must use a different query method or avoid this feature.
• Steps to Reproduce:
  1. Open a SQL session against the local server.
  2. Run a malformed or unsupported JSONPath call such as jsonb_path_query_first with an invalid path and record the error.
  3. Without reconnecting, run a valid JSONPath query and a normal JSONB field extraction.
  4. Run the same valid queries in a second SQL session and compare the values, null results, and types.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: server/functions/jsonb.go:28-38 defines initJsonB and registers only jsonb_in, jsonb_out, jsonb_recv, jsonb_send, jsonb_cmp, jsonb_build_array, and jsonb_build_object. There is no registration for jsonb_path_query_first, jsonb_path_query, jsonb_path_exists, jsonb_path_query_array, jsonb_path_match, or the JSONPath operators, and this file contains no parser or executor for those operations. The catalog metadata in core/id/cache_function_defaults.go:2726-2729 declares JSONPath IO names, while lines 2730-2736 list metadata for JSONPath query and match functions; those entries only identify built-ins and do not provide callable implementations. The regression coverage in testing/go/regression/tests/jsonb_jsonpath.sql:42-57 exercises jsonb_path_exists and error/silent behavior, and lines 68-76 exercises valid jsonb_path_query extraction, but the target function initialization does not wire those calls into the runtime. The recorded error for jsonb_path_query_first being absent is therefore consistent with a production code-level missing-feature defect, not session contamination. The smallest practical fix is to implement and register the JSONPath functions required by the supported regression cases, including the malformed-path error and silent handling, then add a regression check that runs a valid extraction after an error in the same session and in a second session. The PR diff contains only dependency version and checksum changes, so no direct changed line establishes PR causation.

Evidence Package

• text/JSONPATH-3/session-comparison.txt — 650 B
• text/JSONPATH-3/source-registration-evidence.txt — 2 KB

Tip

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