[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	18945	18946
Failures	23145	23144
Partial Successes1	5336	5336

	Main	PR
Successful	45.0107%	45.0131%
Failures	54.9893%	54.9869%

${\color{lightgreen}Progressions (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);

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	2181.30/s	2214.24/s	+1.5%
groupby_scan_postgres	157.72/s	156.30/s	-1.0%
index_join_postgres	694.78/s	702.42/s	+1.0%
index_join_scan_postgres	902.96/s	922.85/s	+2.2%
index_scan_postgres	33.07/s	33.32/s	+0.7%
oltp_delete_insert_postgres	892.62/s	881.19/s	-1.3%
oltp_insert	811.71/s	828.53/s	+2.0%
oltp_point_select	3750.86/s	3839.10/s	+2.3%
oltp_read_only	3443.94/s	3708.65/s	+7.6%
oltp_read_write	2662.23/s	2698.00/s	+1.3%
oltp_update_index	846.95/s	836.25/s	-1.3%
oltp_update_non_index	912.80/s	915.00/s	+0.2%
oltp_write_only	1939.83/s	1936.89/s	-0.2%
select_random_points	2209.79/s	2221.25/s	+0.5%
select_random_ranges	1685.28/s	1688.06/s	+0.1%
table_scan_postgres	33.22/s	33.14/s	-0.3%
types_delete_insert_postgres	926.57/s	923.51/s	-0.4%
types_table_scan_postgres	14.58/s	14.60/s	+0.1%

[itoqa]

Commit: 014147e: 14 test cases ran, 11 passed ✅, 3 additional findings ⚠️.

Summary

The run covered core database workflows including SQL execution, persistence across sessions and restarts, sequence generation, concurrency, type and cast handling, interrupted queries, boundary limits, and invalid-input recovery. It exercised both normal application behavior and edge cases involving exhaustion, concurrent access, session recovery, JSON precision, and type preservation.

Safe to merge — the failures are pre-existing application compatibility and JSON handling defects, with no regressions or other failures attributable to this PR. These remain important follow-up findings, but they are not merge blockers for this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Query	Creating a table, inserting a row, and reading it back all worked through the PostgreSQL connection.
✅	—	Query	The interrupted query was cancelled cleanly and the session closed with a clear exit result. A fresh connection immediately returned the correct SELECT 1 result without leaked rows.
✅	—	Sequence	Three rows were inserted without IDs, and the table generated unique values 1, 2, and 3 in order.
✅	—	Sequence	Separate sessions received unique values, and the sequence kept progressing after compatible branch merges. An opposite-direction branch returned a controlled error instead of creating an unsafe value.
✅	—	Sequence	Ascending and descending sequences reached their int64 limits and then returned controlled exhaustion errors. No value wrapped, repeated, or fell outside the allowed range.
✅	—	Sequence	Dropping and recreating the table did not reuse stale sequence values. New rows received unique ids 3 through 7 after a commit and a new session, and the serial default still pointed to a valid sequence.
✅	—	Sequence	Two independent database sessions committed 25 inserts each. The final readback found 50 rows with 50 distinct IDs, so concurrent inserts did not create duplicates.
✅	—	Storage	The schema, table, primary key, and saved row were all still available in a fresh database session.
✅	—	Storage	The existing schema and table stayed available after a new table was added, committed, and read from a fresh PostgreSQL session.
✅	—	Type	Integer expressions chose the expected types, explicit and assignment casts worked, and an unsupported comparison returned a controlled error without breaking the session.
✅	—	Type	Fresh, warmed, and restarted sessions returned the same values and field types. The local service stayed usable after restart, and persisted data remained readable.
⚠️		Query	Preparing the statement returns an unsupported-feature error, and both attempted executions return the same error instead of reporting the bad value and then returning 42.
⚠️		Type	The JSONB object came back with its large number rounded down by one. The query completed successfully, so a user could trust and store the wrong value.
⚠️		Type	The large number changed from 9007199254740993 to 9007199254740992, and both the JSON and JSONB columns were reported as jsonb after the restart.

Additional Findings Details

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

🟠 Prepared statements cannot recover after bad input

• Severity: High
• Description: Preparing the statement returns an unsupported-feature error, and both attempted executions return the same error instead of reporting the bad value and then returning 42.
• Impact: Applications that use parameterized database queries cannot complete this query workflow. They cannot handle a bad value and then continue with a valid one through the PostgreSQL connection.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL service.
  2. Prepare SELECT $1::int AS value.
  3. Execute it with the value 'not-an-integer' and check that a controlled conversion error is returned.
  4. Execute the same prepared statement with the value 42.
  5. Check that the second execution returns 42.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The local PostgreSQL wire test returned PREPARE is not yet supported for the prepare command and EXECUTE is not yet supported for both executions. The production path confirms this behavior: server/ast/prepare.go:23-29 defines nodePrepare and unconditionally returns NotYetSupportedError("PREPARE is not yet supported") for a non-nil parsed statement; server/ast/execute.go:23-29 defines nodeExecute and unconditionally returns NotYetSupportedError("EXECUTE is not yet supported"). These returns occur before bind conversion or statement execution, so the required invalid-bind recovery behavior is unreachable. The smallest practical fix is to implement the existing prepare and execute AST handlers, including parameter conversion and reuse of the prepared statement; a dependency rollback alone would not fix the untouched handlers. The PR context shows only version changes in go.mod and checksum changes in go.sum, with no changed lines in either handler, so introduced_by_this_pr is False.

Evidence Package

• text/QUERY-2/QUERY-2-prepared-statement-run.txt — 920 B
• text/QUERY-2/QUERY-2-prepared-statement-source.txt — 933 B

🟠 JSON numbers lose precision when read back

• Severity: High
• Description: The JSONB object came back with its large number rounded down by one. The query completed successfully, so a user could trust and store the wrong value.
• Impact: When JSONB contains sufficiently large numbers, reading the value can silently change it, so users may rely on incorrect data. Other tested scalar and numeric values are unaffected.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL service as the postgres user.
  2. Create a table with a JSONB column.
  3. Insert the JSON object {"n":9007199254740993,"ok":true}.
  4. Select the JSONB value as text and compare the returned number with the inserted number.
  5. Observe that the returned object contains 9007199254740992 instead of 9007199254740993.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The failure is reproduced over the local PostgreSQL wire path: the evidence shows the inserted JSONB number 9007199254740993 returned as 9007199254740992, while int8, numeric, NULL, and type metadata round-tripped correctly. In server/types/jsonb.go, serializeTypeJsonB unwraps a sql.JSONWrapper with ToInterface and then passes the result to ConvertToJsonDocument (lines 68-92). The conversion function has a precision-unsafe float64 branch at server/types/json_document.go:314-321; it scans the already-rounded float64 into an apd.Decimal and therefore cannot recover the original JSON number. The same file has a json.Decoder.UseNumber path at lines 231-245 and a json.Number branch at lines 298-313, but the active wire/storage path observed in this run still produced the rounded result, so the precision guarantee is not maintained end to end. The binary COPY error is excluded: server/ast/copy_from.go:32-34 explicitly rejects COPY FROM BINARY, whereas the test requirement was binary result output, not binary COPY input.

Evidence Package

• text/TYPE-1/TYPE-1-jsonb-precision-loss.txt — 2 KB

🟠 JSON values lose type and precision

• Severity: High
• Description: The large number changed from 9007199254740993 to 9007199254740992, and both the JSON and JSONB columns were reported as jsonb after the restart.
• Impact: Users storing large whole numbers in JSON can get a different number back even though the query succeeds. JSON columns can also come back with the wrong type, which can break clients that rely on the declared type.
• Steps to Reproduce:
  1. Connect to the local PostgreSQL service.
  2. Create a table with JSON, JSONB, numeric, varchar, and text-array columns.
  3. Insert JSON containing the number 9007199254740993 and values for the other columns.
  4. Read the row and record the values and their PostgreSQL type names.
  5. Restart the local database process and read the same row again.
  6. Compare the JSON number and type names with the inserted values.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The persisted result matches two source-level defects. In postgres/parser/types/types.go:102-103, the built-in type table maps both SQL JSON and SQL JSONB to the JSONB family and T_jsonb OID, so a declared JSON column cannot retain distinct PostgreSQL type metadata through resolution and wire output. The precision loss is consistent with server/types/jsonb.go:74-85, where a JSONWrapper is converted through ToInterface before being rebuilt as a JsonDocument; server/types/json_document.go:298-313 preserves json.Number, but the float64 fallback at lines 314-321 explicitly scans an already-rounded float64 and is marked as not precise enough. The recorded value demonstrates that the value reached that lossy fallback somewhere in the JSON wrapper path. The smallest practical fix is to preserve the original number text or a string-backed json.Number through every JSONWrapper conversion, rather than converting it to float64, and to give JSON its own registered type/OID and wire metadata instead of aliasing it to JSONB.

Evidence Package

• text/TYPE-4/TYPE-4-persisted-wire-readback.txt — 3 KB

Tip

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