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

[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	18950	18946
Failures	23140	23144
Partial Successes1	5340	5336

	Main	PR
Successful	45.0226%	45.0131%
Failures	54.9774%	54.9869%

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	2490.58/s	2464.96/s	-1.1%
groupby_scan_postgres	147.70/s	143.24/s	-3.1%
index_join_postgres	688.40/s	677.02/s	-1.7%
index_join_scan_postgres	895.60/s	877.09/s	-2.1%
index_scan_postgres	34.92/s	35.30/s	+1.0%
oltp_delete_insert_postgres	577.87/s	619.21/s	+7.1%
oltp_insert	551.94/s	575.52/s	+4.2%
oltp_point_select	4797.55/s	4819.45/s	+0.4%
oltp_read_only	4107.49/s	4112.96/s	+0.1%
oltp_read_write	2588.74/s	2528.19/s	-2.4%
oltp_update_index	614.00/s	556.47/s	-9.4%
oltp_update_non_index	617.24/s	564.14/s	-8.7%
oltp_write_only	1598.33/s	1581.14/s	-1.1%
select_random_points	2099.49/s	2133.34/s	+1.6%
select_random_ranges	1663.85/s	1663.33/s	-0.1%
table_scan_postgres	34.88/s	35.22/s	+0.9%
types_delete_insert_postgres	575.61/s	581.02/s	+0.9%
types_table_scan_postgres	15.51/s	15.95/s	+2.8%

[itoqa]

Commit: e5c7706: 14 test cases ran, 13 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans clean builds and release packaging, dependency integrity, startup and restart behavior, PostgreSQL queries and transactions, schema changes, concurrent sessions, persistence, compatibility handling, and recovery-related edge cases. It also exercises adversarial inputs such as tampered dependencies, duplicate-key recovery, unsupported storage versions, and large JSON numbers; core behavior is broadly healthy, with an unrelated existing JSON feature and precision defect identified.

Safe to merge — the only failure is not attributable to this PR and shows no regression, new failure, or previously flagged PR issue. The unrelated JSON defect is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Build	The application compiled from an empty module cache, all Go tests passed, and the new binary accepted a local PostgreSQL connection. The project wrapper could not run because Docker was unavailable inside the test container, but the direct build verified the application itself.
✅	—	Build	The dependency versions resolved consistently from a clean cache, and checksum verification rejected a changed module instead of using it.
✅	—	Build	The release binary created and saved the example database, then reopened all three tables with the same rows, commit history, and clean status after restart.
✅	—	Build	The release scripts declare Windows, Linux, and macOS targets and provide build and packaging settings for each one. The full matrix could not run because this Linux test environment lacks Docker and the required cross-compilers, so the blocked launch attempts do not show a product failure.
✅	—	Engine	Simple queries, data changes, parameterized queries, and transaction commits all worked as expected. The separate SQL PREPARE command is documented as unsupported, but that command is not the PostgreSQL wire-protocol prepared-query path this test was meant to check.
✅	—	Engine	Renaming the table and column, adding a column, and changing a column type all succeeded. The final schema, constraints, rows, and Dolt status matched the resulting table.
✅	—	Engine	Simple and prepared queries returned the same numeric value and type. After a duplicate-key error, the next insert still succeeded, the transaction committed, and a new session could see the committed row.
✅	—	Startup	A fresh server accepted the default postgres login on port 5432. Built-in expressions, the default database, the Dolt status table, and the ready message all worked, and the metrics listener stayed disabled by default.
✅	—	Startup	Eight sessions opened after a warm restart and all returned the same calculated value, type, and saved row. The server stayed healthy and accepted the persisted data without errors.
✅	—	Storage	The database reopened after restart with its existing rows and commit history. A new employee was also committed and read successfully.
✅	—	Storage	A repository made by a newer version is refused before it can be opened or used.
✅	—	Storage	The backup check found no source-backed path that mixes data from different commits. The local target became unavailable before the full backup and restore workflow could finish, so this case is included as a setup reclassification rather than a product failure.
✅	—	Storage	The persisted repository reopened with its tables, foreign key, type, sequence, routine, and trigger relationships available. Dependent SQL and sequence reads worked; the full backup and restore comparison could not be completed because the local PostgreSQL service was unavailable and some catalog operations were unsupported.
⚠️		Build	The JSONPath query reports that jsonb_path_query_first does not exist. The JSON value also changes 9007199254740993 to 9007199254740992, both before and after restart.

Additional Findings Details

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

🟠 JSONPath queries fail and large numbers lose precision

• Severity: High
• Description: The JSONPath query reports that jsonb_path_query_first does not exist. The JSON value also changes 9007199254740993 to 9007199254740992, both before and after restart.
• Impact: People using nested JSON queries may get an error instead of results, and large numeric values may be changed to a different number. This can lead to wrong filters, calculations, or saved decisions.
• Steps to Reproduce:
  1. Build the binary after clearing the Go module and build caches.
  2. Start the binary with a temporary local data directory and connect through PostgreSQL on port 5432.
  3. Run jsonb_path_query_first('{"big":9007199254740993,"nested":{"value":42}}'::jsonb, '$.nested.value').
  4. Run a JSON query that reads the big value and compare the result with the input value 9007199254740993.
  5. Repeat the same queries after restarting the binary without clearing its data, and compare both results.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime failure is supported by two independent source paths. First, core/id/cache_function_defaults.go:2730-2736 adds jsonb_path_exists, jsonb_path_query, jsonb_path_query_array, jsonb_path_query_first, jsonb_path_match, and related operator entries to the built-in catalog. However, server/functions/binary/json.go:initJSON at lines 59-81 registers only JSON extraction, containment, existence, and deletion functions; it contains no JSONPath function objects or registrations. This creates a catalog entry that the SQL resolver can advertise but the server cannot execute, matching the observed function: 'jsonb_path_query_first' not found error. Second, postgres/parser/json/json.go:713-734 explicitly calls json.Decoder.UseNumber at lines 719-723 and passes the string-backed number into MakeJSON, while server/types/json_document.go:231-245 similarly uses UseNumber before ConvertToJsonDocument. Those paths are intended to preserve arbitrary numeric precision, so the observed conversion of 9007199254740993 to 9007199254740992 is a downstream representation or output defect rather than a cache or compilation artifact. The smallest practical remediation is to implement and register the advertised JSONPath functions, then trace the JSON wrapper/output conversion used by this query and preserve json.Number or the repository's arbitrary-precision decimal through that path instead of converting through float64. The PR diff in pr-context.json changes only go.mod and go.sum, so no changed line provides a direct causal path.

Evidence Package

• text/BUILD-4/BUILD-4-jsonpath-runtime.txt — 2 KB
• text/BUILD-4/BUILD-4-jsonpath-source-investigation.txt — 2 KB

Tip

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

[github-actions]

This PR has been superseded by #3067