[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	18945
Failures	23140	23145
Partial Successes1	5340	5336

	Main	PR
Successful	45.0226%	45.0107%
Failures	54.9774%	54.9893%

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

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	2025.37/s	2092.26/s	+3.3%
groupby_scan_postgres	138.29/s	147.24/s	+6.4%
index_join_postgres	657.65/s	653.17/s	-0.7%
index_join_scan_postgres	834.67/s	836.52/s	+0.2%
index_scan_postgres	31.03/s	30.70/s	-1.1%
oltp_delete_insert_postgres	827.76/s	780.19/s	-5.8%
oltp_insert	739.61/s	721.82/s	-2.5%
oltp_point_select	3473.29/s	3454.98/s	-0.6%
oltp_read_only	3430.06/s	3329.94/s	-3.0%
oltp_read_write	2484.79/s	2368.99/s	-4.7%
oltp_update_index	759.29/s	704.91/s	-7.2%
oltp_update_non_index	799.66/s	762.41/s	-4.7%
oltp_write_only	1779.98/s	1653.81/s	-7.1%
select_random_points	2097.58/s	2058.40/s	-1.9%
select_random_ranges	1569.53/s	1547.90/s	-1.4%
table_scan_postgres	30.81/s	30.23/s	-1.9%
types_delete_insert_postgres	799.23/s	763.22/s	-4.6%
types_table_scan_postgres	13.97/s	13.79/s	-1.3%

[itoqa]

Commit: 529454c: 9 test cases ran, 4 passed ✅, 5 additional findings ⚠️.

Summary

Coverage spans core database behavior and lifecycle flows, including data persistence across restarts and upgrades, concurrent identifier generation, and clean startup and shutdown. It also probes edge and compatibility cases involving mixed numeric types, prepared statements, large text boundaries, escaped JSON keys, and JSON path queries.

Safe to merge — none of the observed failures are attributable to this PR, so there is no identified regression or merge blocker. Pre-existing medium-severity SQL, JSON, and shutdown limitations should be tracked separately as follow-up work.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Sequence	Saved sequence values and generated row numbers remained available after the server restarted with the same data directory. The earlier empty result came from the local server stopping and an overly strict readiness check, not from a repeatable product failure.
✅	—	Sequence	Concurrent sessions received different row IDs. Rolled-back inserts left normal gaps, and the next ID after restart was 13.
✅	—	Storage	A saved table and row were still available after the local database server was stopped and started again.
✅	—	Storage	The upgraded server opened data created by the previous version, kept the original row, accepted new rows and branch changes, and returned all data after restart.
⚠️		Engine	The server returned numeric UNION values with a text type instead of a stable common numeric type. It also rejected prepared statements instead of accepting and executing them.
⚠️		Engine	The supported varchar values could be read after restart, but a boundary comparison caused a panic while converting the stored text value. The expected behavior was a successful comparison or a controlled validation error without a panic.
⚠️		Json	The escaped-quote key a"b returned NULL in the indexed JSONB lookup even though the object contains that key with value 7. The separate check that JSON null converted with ->> should be SQL NULL was not a product failure: PostgreSQL returns the text value null for that operator, while the retry confirmed ->> itself returns SQL NULL in the tested case.
⚠️		Json	The database returned an error when the test tried to compare a JSONB value with a JSON path and when it called a JSON path query. The same documents and their direct nested, array, number, and null values were readable before and after restart, so persistence was not the failure.
⚠️		Startup	After SIGINT, the listener closed and the server stopped accepting connections, but the Doltgres process with PID 37619 remained alive. The shutdown log did not show a process exit, so the clean-shutdown requirement was not met.

Additional Findings Details

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

🟡 Mixed SQL types return wrong results

• Severity: Medium
• Description: The server returned numeric UNION values with a text type instead of a stable common numeric type. It also rejected prepared statements instead of accepting and executing them.
• Impact: Applications that combine different number types in a UNION may receive values as text, causing client decoding or follow-up query failures. Applications that use prepared statements cannot run those queries.
• Steps to Reproduce:
  1. Connect to the local SQL server with a PostgreSQL client.
  2. Run a UNION ALL query that combines an int4 value with an int8 value, then check the result with pg_typeof.
  3. Run another UNION ALL query that combines a numeric value with an integer value, then check the result with pg_typeof.
  4. Run PREPARE for a statement that compares or combines typed parameters, then execute it.
  5. Observe that the UNION values are reported as text and PREPARE returns an unsupported-feature error.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The observed UNION behavior is supported by server/ast/union_clause.go:26-68. nodeUnionClause converts the left and right SELECT nodes and chooses only the Vitess set-operation name, then returns a vitess.SetOp at lines 64-68 without resolving or propagating PostgreSQL common column types. The comments at lines 62-63 explicitly leave result-type handling as an unresolved TODO, which explains why int4/int8 and numeric/integer UNION outputs were exposed as text. The prepared-statement failure is unconditional in server/ast/prepare.go:23-30: nodePrepare returns NotYetSupportedError("PREPARE is not yet supported") for every non-nil PREPARE node. The PR context shows only go.mod and go.sum dependency-version/checksum edits, so neither production path is a changed line in this PR. The smallest practical fix is to implement common-type resolution and casts when constructing UNION output columns, and separately replace the unconditional PREPARE rejection with the existing prepared-statement execution path or a narrowly scoped implementation for the supported parameter forms.

Evidence Package

• text/ENGINE-1/ENGINE-1-sql-compatibility-evidence.txt — 4 KB

🟡 Boundary text comparison crashes the server

• Severity: Medium
• Description: The supported varchar values could be read after restart, but a boundary comparison caused a panic while converting the stored text value. The expected behavior was a successful comparison or a controlled validation error without a panic.
• Impact: A query comparing a supported large varchar value can fail with a panic instead of returning a result or a clear error. This blocks that boundary query, but ordinary values and the database server continue to work.
• Steps to Reproduce:
  1. Create columns using varchar(10), unbounded varchar, and a supported large width such as varchar(64479).
  2. Insert values at those widths and restart the local SQL server.
  3. Run a comparison or grouped boundary query that reads the large varchar value.
  4. Observe that the query recovers an interface-conversion panic instead of returning a value or a controlled error.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production path is explicit in server/types/varchar.go. VarChar assigns serializeTypeVarChar as its SerializationFunc at lines 73-75. serializeTypeVarChar at lines 115-119 immediately evaluates str := val.(string), then writes the string bytes. The recovered failure identifies the actual value as *val.TextStorage, so the assertion cannot succeed when the engine supplies that storage-backed representation. This explains the reported interface conversion panic rather than a browser or local-server setup problem. The smallest practical fix is to make serializeTypeVarChar handle the storage-backed text representation through the supported text conversion path, or return a normal error for an unsupported value type, before writing the serialized bytes. The PR diff only updates dependency versions and checksums in go.mod and go.sum; it contains no change to server/types/varchar.go or this call path, so there is no direct changed-line causal link to this defect.

Evidence Package

• text/ENGINE-2/ENGINE-2-boundary-comparison-evidence.txt — 3 KB

🟡 Escaped JSON keys return no value

• Severity: Medium
• Description: The escaped-quote key a"b returned NULL in the indexed JSONB lookup even though the object contains that key with value 7. The separate check that JSON null converted with ->> should be SQL NULL was not a product failure: PostgreSQL returns the text value null for that operator, while the retry confirmed ->> itself returns SQL NULL in the tested case.
• Impact: Queries for JSON object keys containing double quotes can return NULL instead of the stored value. This can make an existing value look missing, but ordinary keys and other JSONB lookups continue to work.
• Steps to Reproduce:
  1. Create or query the JSONB value {"a"b":7}.
  2. Read the object field using the key a"b.
  3. Compare the result with the expected JSON value 7 and with a normal key such as a.
• Stub / mock content: The test used a local Doltgres server and direct SQL fixtures. No stubs, mocks, or application-code bypasses were applied.
• Code Analysis: The production path is in server/functions/binary/json.go. jsonb_object_field at lines 251-295 detects a comparable JSON wrapper at lines 266-269 and sends the key to types.LookupJSONValue using makeObjectKeyPath(key). makeObjectKeyPath delegates to objectKeyPathSegment at lines 30-41, which creates a quoted MySQL JSON path and escapes every double quote with a backslash. The recorded raw SQL result returned NULL for the literal key a"b, while testing/go/json_function_test.go:124-128 explicitly requires SELECT '{"a"b":7}'::jsonb -> 'a"b' to return 7. The materialized fallback at lines 278-294 performs a direct map lookup and would preserve the literal key, but comparable/indexed wrappers take the fast path before reaching it. The smallest practical fix is to make the comparable lookup encode double-quote keys in the path format expected by types.LookupJSONValue, or to fall back to the direct map lookup for keys containing quotes until that encoding is corrected.

Evidence Package

• text/JSON-1/JSON-1-escaped-key-evidence.txt — 2 KB

🟡 JSON path queries cannot run

• Severity: Medium
• Description: The database returned an error when the test tried to compare a JSONB value with a JSON path and when it called a JSON path query. The same documents and their direct nested, array, number, and null values were readable before and after restart, so persistence was not the failure.
• Impact: Users who rely on JSONPath queries cannot compare or query JSON documents through the advertised database features. Direct JSONB reads and writes still work, so other JSON workflows remain available.
• Steps to Reproduce:
  1. Create a table with a JSONB document containing nested objects and arrays.
  2. Run a JSON path comparison such as jsonb '{"a": 12}' @? '$.a' or call jsonb_path_query('[1]', 'strict $[1]').
  3. Observe that the operator or function cannot be resolved instead of returning the matching JSON value.
  4. Restart the local database and run the same JSON path query again; the direct JSONB values remain available, but the JSON path query is still unavailable.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The regression test testing/go/regression/tests/jsonb_jsonpath.sql:1-7 exercises the @? operator, and line 21 calls jsonb_path_query. The catalog defaults in core/id/cache_function_defaults.go:2726-2736 list jsonpath_in, jsonpath_recv, jsonpath_out, jsonpath_send, jsonb_path_exists, jsonb_path_query, jsonb_path_query_array, jsonb_path_query_first, jsonb_path_match, and the JSON path operators. Those entries only advertise catalog IDs and signatures. The server function initialization in server/functions/init.go:17-50 calls initJson and initJsonB but has no jsonpath initializer. server/functions/jsonb.go:28-38 registers only JSONB input/output, comparison, and build functions; it registers none of the advertised JSON path functions or operators. A repository-wide search also finds no executable server implementation for jsonb_path_query, jsonb_path_exists, or the @? operator. The smallest practical fix is to register the existing JSON path implementation, if present in the dependency, or add the specific missing function/operator handlers and initialize them; the catalog-only entries must not be exposed until those handlers can execute.

Evidence Package

• text/JSON-2/JSON-2-jsonpath-capability-evidence.txt — 4 KB

🟡 Server stays running after shutdown

• Severity: Medium
• Description: After SIGINT, the listener closed and the server stopped accepting connections, but the Doltgres process with PID 37619 remained alive. The shutdown log did not show a process exit, so the clean-shutdown requirement was not met.
• Impact: Stopping the server can leave a background process alive even though it no longer accepts connections. Operators and cleanup scripts may need to find and kill the leftover process before restarting or releasing resources.
• Steps to Reproduce:
  1. Build the Doltgres binary and start it with a new isolated data directory.
  2. Connect to localhost:5432 and run SELECT 1 and a simple table insert/readback.
  3. Send SIGINT to the exact Doltgres process ID.
  4. Check whether that process exits after the listener closes; in the recorded run it remained alive after 30 polling attempts.
• Stub / mock content: The Docker-based build wrapper was unavailable inside the nested test container, so the binary was built directly with CGO enabled. No application mocks, route interception, or test-data bypasses were applied.
• Code Analysis: cmd/doltgres/main.go:230-237 converts SIGINT and SIGTERM into cancellation of the root context, then calls runServer and exits only after runServer returns. cmd/doltgres/main.go:337-354 starts the on-disk server with server.RunOnDisk and blocks on controller.WaitForStop(), so a normal signal must both close the listener and allow the controller to reach its stopped state. In server/server.go:160-173, runServer creates a child context and a goroutine that waits for controller.WaitForStart(), then waits for the parent context to finish, calls controller.Stop(), and cancels the child context. The observed sequence reached the listener-close log but did not terminate PID 37619 within 30 polls, which indicates that shutdown completion is not being propagated through the controller wait path or that a shutdown-owned goroutine/resource is keeping the process alive. The smallest practical fix is to trace the controller.Stop/WaitForStop completion path for this startup configuration and ensure the signal-triggered stop waits for all server services to finish before returning; add a process-exit assertion to the startup shutdown test.

Evidence Package

• text/STARTUP-1/STARTUP-1-startup-shutdown-evidence.txt — 2 KB

Tip

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

[github-actions]

This PR has been superseded by #3066