[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	18948	18948
Failures	23142	23142
Partial Successes1	5336	5336

	Main	PR
Successful	45.0178%	45.0178%
Failures	54.9822%	54.9822%

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	2072.85/s	2076.15/s	+0.1%
groupby_scan_postgres	145.14/s	146.90/s	+1.2%
index_join_postgres	656.48/s	658.53/s	+0.3%
index_join_scan_postgres	836.87/s	833.49/s	-0.5%
index_scan_postgres	30.92/s	31.43/s	+1.6%
oltp_delete_insert_postgres	810.09/s	806.75/s	-0.5%
oltp_insert	744.39/s	737.35/s	-1.0%
oltp_point_select	3453.00/s	3456.02/s	0.0%
oltp_read_only	3422.47/s	3415.08/s	-0.3%
oltp_read_write	2536.97/s	2547.51/s	+0.4%
oltp_update_index	776.98/s	763.02/s	-1.8%
oltp_update_non_index	796.37/s	823.29/s	+3.3%
oltp_write_only	1803.17/s	1838.91/s	+1.9%
select_random_points	2137.30/s	2127.31/s	-0.5%
select_random_ranges	1557.92/s	1567.36/s	+0.6%
table_scan_postgres	30.21/s	30.83/s	+2.0%
types_delete_insert_postgres	835.01/s	836.55/s	+0.1%
types_table_scan_postgres	13.71/s	13.84/s	+0.9%

[itoqa]

Commit: 582bb4a: 14 test cases ran, 12 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans core database behavior including ordinary queries, prepared statements, generated identifiers, concurrent writes, branch and reopen persistence, bounded sequences, complex values, and recovery after errors. It includes happy paths, boundary conditions, concurrency, persistence, and error-handling scenarios, with overall application behavior healthy aside from known unrelated findings.

Safe to merge — no observed failure is attributable to this PR, so there is no merge-blocking regression or new defect indicated. The unrelated pre-existing sequence and branch-state issues should remain flagged for later remediation.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Build	The local database accepted a connection, returned one row containing 1, and closed the session cleanly.
✅	—	Build	The application built successfully with an empty module cache and with a warmed cache. Both builds produced the same checksums, the server returned the expected schema and SQL results, and the client closed cleanly.
✅	—	Sequence	The sequence returned 0, -2, and -4 as expected, then rejected the next allocation at its minimum instead of crossing the lower bound.
✅	—	Sequence	Ascending allocation returned 1, 2, and 3, while descending allocation returned 0, -1, and -2. The next value in each direction was rejected at the exact limit, and reconnecting preserved the rows and sequence state.
✅	—	Sequence	Four separate sessions committed 25 inserts each. The table contained 100 rows with 100 unique IDs from 1 through 100, and the next generated ID was 101.
✅	—	Session	The server accepted a standard client connection, returned 1 for SELECT 1, and disconnected without an error.
✅	—	Session	The server accepted the prepared query, returned 5 for input 4, and returned 10 for input 9 on the same connection without an error.
✅	—	Session	A failed statement inside a transaction returned an error, but the session remained usable after rollback. A later query succeeded and a fresh connection also worked normally.
✅	—	Sql	The database returned the requested number, NULL, array, record, JSON value, and running totals of 10, 30, and 60.
✅	—	Sql	Repeated array comparisons returned the expected true and false values, and an array containing NULL followed SQL's three-valued rules without an error.
✅	—	Sql	A mixed array, record, JSON, and NULL query returned the expected values. A malformed JSON value produced a controlled error, and a later valid query succeeded on the same connection.
✅	—	Storage	The committed schema, table, and row were still visible after switching branches, merging the changes, and opening a fresh connection.
⚠️		Sequence	After two SERIAL inserts generated IDs 1 and 2, calling currval for the sequence returned function: 'currval' not found. The later value observed in a new session was affected by the failed statement rolling back its sequence update; that rollback is a consequence of the missing function failure, not a reset in the sequence allocator.
⚠️		Storage	The main branch did not keep its sequence aligned with its visible table snapshot. It returned 105 even though the branch contains no rows 102, 103, or 104.

Additional Findings Details

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

🟡 Sequence current value lookup fails

• Severity: Medium
• Description: After two SERIAL inserts generated IDs 1 and 2, calling currval for the sequence returned function: 'currval' not found. The later value observed in a new session was affected by the failed statement rolling back its sequence update; that rollback is a consequence of the missing function failure, not a reset in the sequence allocator.
• Impact: Applications cannot read the sequence value they just generated through the standard current-value function. This can break workflows that need the generated ID after an insert, though the insert itself still succeeds.
• Steps to Reproduce:
  1. Create a sequence and a table with a SERIAL-generated ID.
  2. Insert two rows and call currval on the sequence in the same session.
  3. Observe that the call fails with a function-not-found error instead of returning the latest value.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The built-in catalog declares pg_catalog.currval(regclass) at core/id/cache_function_defaults.go:957, so name and signature resolution advertise the function to clients. The analyzer also explicitly recognizes currval alongside nextval and setval in server/analyzer/optimize_functions.go:52-56 and applies sequence authorization checks to it, which confirms that the execution pipeline expects a compiled sequence function. However, server/functions/nextval.go:30-34 registers only nextval_text and nextval_regclass, and that file contains the only nextval implementation path; no currval implementation or registration exists under server/functions. Consequently, a valid currval(regclass) expression can be catalog-visible and analyzer-recognized but cannot be dispatched at runtime, matching the observed function-not-found error. The smallest practical fix is to add a currval implementation that reads the current session's sequence tracker value for the resolved sequence and register its regclass (and any required text-compatible) overload in the same function registry. The implementation should return PostgreSQL's expected error when the sequence has not been called in the current session, without allocating or advancing a new value.

Evidence Package

• text/SEQUENCE-1/SEQUENCE-1-currval-failure.txt — 4 KB

🟡 Branch sequence skips visible rows

• Severity: Medium
• Description: The main branch did not keep its sequence aligned with its visible table snapshot. It returned 105 even though the branch contains no rows 102, 103, or 104.
• Impact: After switching branches, users may receive IDs that do not match the rows visible in the active branch. This makes branch-local storage unreliable and can leave unexpected gaps in generated IDs.
• Steps to Reproduce:
  1. On the main branch, create the table and sequence, insert rows with IDs 100 and 101, and commit the snapshot.
  2. Switch to a feature branch and insert another row, which advances the sequence to allocate 103; call nextval again to observe 104.
  3. Switch back to main and open a fresh session, then read the table and call nextval.
  4. Compare the main table rows with the generated value: main shows only 100 and 101, but nextval returns 105.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The runtime readback shows the feature branch with rows 100, 101, and 103 and nextval 104, while a fresh main session shows only rows 100 and 101 and nextval 105. This matches the production implementation in core/sequences/collection.go:73-99: SequenceState.Merge combines sequence states and, for an ascending sequence, selects the state with the greater current value through GreaterThan, so a state advanced on the feature branch can become the merged current value. core/sequences/collection.go:147-188 then returns the current value from that merged state and advances it, making the cross-branch value visible to nextval. In contrast, core/rootobject/objinterface/root_object_map.go:35-46 loads each collection from the supplied root snapshot, so table visibility remains branch-specific. core/context.go:463-508 writes cached collections back to the session working root but does not add branch-local isolation for the SequenceTracker merge policy. The smallest practical fix is to make sequence state used for nextval resolve from the active branch root, or otherwise prevent states from unrelated branch roots from being merged into that allocation; add a regression test for the 100/101, feature 103, main nextval scenario.

Evidence Package

• text/STORAGE-2/branch-sequence-trigger-and-readback.txt — 2 KB
• text/STORAGE-2/sequence-merge-code-path.txt — 2 KB

Tip

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

[github-actions]

This PR has been superseded by #3074