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

[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]

This PR has been superseded by #3079

[github-actions]

	Main	PR
Total	42090	42090
Successful	18407	18406
Failures	23683	23684
Partial Successes1	5327	5327

	Main	PR
Successful	43.7325%	43.7301%
Failures	56.2675%	56.2699%

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

subselect

QUERY:          select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);
RECEIVED ERROR: timeout during Receive

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	3430.05/s	3582.24/s	+4.4%
groupby_scan_postgres	209.44/s	207.75/s	-0.9%
index_join_postgres	999.22/s	1010.97/s	+1.1%
index_join_scan_postgres	1264.50/s	1241.24/s	-1.9%
index_scan_postgres	50.52/s	51.84/s	+2.6%
oltp_delete_insert_postgres	411.67/s	416.45/s	+1.1%
oltp_insert	440.67/s	${\color{red}336.02/s}$	${\color{red}-23.8\%}$
oltp_point_select	6443.12/s	6462.82/s	+0.3%
oltp_read_only	5787.53/s	5950.71/s	+2.8%
oltp_read_write	1583.60/s	1658.27/s	+4.7%
oltp_update_index	314.52/s	${\color{red}240.73/s}$	${\color{red}-23.5\%}$
oltp_update_non_index	191.54/s	${\color{lightgreen}323.78/s}$	${\color{lightgreen}+69.0\%}$
oltp_write_only	1348.22/s	1346.54/s	-0.2%
select_random_points	3289.88/s	3284.86/s	-0.2%
select_random_ranges	2491.83/s	2479.79/s	-0.5%
table_scan_postgres	52.44/s	53.70/s	+2.4%
types_delete_insert_postgres	609.51/s	566.53/s	-7.1%
types_table_scan_postgres	23.84/s	24.27/s	+1.8%

[itoqa]

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

Summary

Coverage spans core database behavior across normal use, persistence and restart flows, concurrent ID generation, branch merges, schema changes, connection initialization, boundary conditions, null and empty-result handling, and cross-client query compatibility. The exercised paths include happy-path operations plus concurrency, restart, merge, limit, and incompatible-state edge cases.

Safe to merge — the only failure is a medium-severity, pre-existing prepared-statement compatibility gap that is explicitly unrelated to this PR, with no regressions or PR-attributable failures identified. It is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Engine	Window and aggregate queries returned the expected values for grouped rows, ties, nulls, and empty results.
✅	—	Sequence	Two database sessions received different values, 3 and 4. After the sequence was committed and the server restarted, the next call returned 7, showing that the saved sequence state advanced correctly.
✅	—	Sequence	Merging branches with opposite sequence directions leaves the sequence unusable instead of returning a possibly unsafe identifier. The test captured the expected incompatible-state error after the merge.
✅	—	Sequence	A sequence returned the largest positive value and the smallest negative value once. The next call stopped with a clear boundary error instead of wrapping to an unexpected value.
✅	—	Sequence	Four concurrent sessions inserted 100 rows, and every row received a different ID. The IDs were still durable after restart, with the next ID advancing past the highest saved value.
✅	—	Sequence	Rows from both branches stayed unique after the merge. A new row received ID 6, and the next sequence value was 7 after restart.
✅	—	Server	The default PostgreSQL listener accepted the documented login on fresh and warmed connections. A created row, built-in version information, and the same row after a clean restart were all available.
✅	—	Server	The server accepted the configured administrator login, used the custom data folder, and kept the created table after a restart. The earlier failure came from checking a database that did not exist, not from the server rejecting the configured identity.
✅	—	Server	A second connection opened while the server was warm returned the same user, version, table, and metadata results as the first connection. The same checks also worked after a clean restart, so no initialization-order problem was found.
✅	—	Server	Rapid connections during normal startup and after a clean restart all authenticated successfully and returned the built-in version result and table lookup.
✅	—	Storage	The committed table and its saved row were still available after the database server restarted.
✅	—	Storage	A repository with older storage data accepted a new schema and table. The table was committed and its row was still readable afterward without a decoding error.
✅	—	Storage	The table kept its merged columns after the server restarted. A new column was then added and committed successfully, with no leftover changes reported.
⚠️		Engine	The prepared-query check failed because psql rejected SQL PREPARE with the message "PREPARE is not yet supported". The Node client succeeded, so the two clients do not support the same prepared-query contract.

Additional Findings Details

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

🟡 SQL prepared statements are unsupported

• Severity: Medium
• Description: The prepared-query check failed because psql rejected SQL PREPARE with the message "PREPARE is not yet supported". The Node client succeeded, so the two clients do not support the same prepared-query contract.
• Impact: Applications that use SQL prepared statements through clients such as psql cannot run those queries, while another client path works. Teams must switch clients or avoid prepared statements until support is added.
• Steps to Reproduce:
  1. Connect to the local database with psql and create or use a table containing the query data.
  2. Run the compatibility query directly in psql and confirm that its rows, NULL values, column names, and types match the Node client.
  3. Run the same query as a SQL prepared statement with PREPARE in psql.
  4. Run the equivalent named prepared query through the Node client and compare the result.
  5. Observe that psql returns PREPARE is not yet supported while the Node client returns the expected rows and metadata.
• Stub / mock content: The test used a local PostgreSQL-compatible server and a temporary installation of the documented Node pg client; no application routes, database responses, or query behavior were mocked or bypassed.
• Code Analysis: The failure is deterministic in the production code. server/ast/convert.go:184-185 routes every parsed *tree.Prepare statement to nodePrepare. server/ast/prepare.go:23-30 checks for nil and then unconditionally returns NotYetSupportedError("PREPARE is not yet supported"), so a SQL PREPARE statement can never reach execution. Separately, server/connection_handler.go:653-725 implements the PostgreSQL extended-protocol Parse path: it converts the query, analyzes it with ComPrepareParsed, infers parameter types, stores PreparedStatementData, and sends ParseComplete. That separate path explains why Node pg named preparation succeeds while psql SQL PREPARE fails. The smallest practical fix is to implement nodePrepare using the existing prepared-statement registration/execution machinery, or otherwise route SQL PREPARE through the same supported prepared-statement path; removing the unconditional error alone would not be sufficient.

Evidence Package

• text/ENGINE-2/ENGINE-2-prepared-query-comparison.txt — 3 KB
• text/ENGINE-2/ENGINE-2-prepare-source-path.txt — 2 KB

Tip

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