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

	Main	PR
covering_index_scan_postgres	1784.32/s	1767.02/s	-1.0%
groupby_scan_postgres	134.16/s	129.66/s	-3.4%
index_join_postgres	635.95/s	633.13/s	-0.5%
index_join_scan_postgres	781.88/s	770.43/s	-1.5%
index_scan_postgres	24.02/s	23.85/s	-0.8%
oltp_delete_insert_postgres	742.43/s	754.41/s	+1.6%
oltp_insert	659.96/s	648.46/s	-1.8%
oltp_point_select	2785.58/s	2726.82/s	-2.2%
oltp_read_only	2843.86/s	2780.20/s	-2.3%
oltp_read_write	2214.45/s	2225.07/s	+0.4%
oltp_update_index	693.06/s	674.10/s	-2.8%
oltp_update_non_index	725.51/s	705.64/s	-2.8%
oltp_write_only	1699.95/s	1697.12/s	-0.2%
select_random_points	1795.80/s	1736.61/s	-3.3%
select_random_ranges	1057.20/s	1026.65/s	-2.9%
table_scan_postgres	22.71/s	22.35/s	-1.6%
types_delete_insert_postgres	732.61/s	731.61/s	-0.2%
types_table_scan_postgres	7.86/s	7.94/s	+1.0%

[itoqa]

Commit: 833e50a: 10 test cases ran, 0 failed ❌, 9 passed ✅, 1 additional finding ⚠️.

Summary

Coverage exercised core database behavior across normal query and write flows, prepared statement/type handling, command tagging, schema lifecycle and concurrent schema changes, plus restart persistence, and those paths behaved as expected. It also included an adversarial file-import security edge case that exposed a known weakness outside this PR’s changes.

Safe to merge — the only observed issue is a pre-existing minor security hardening gap in an edge-case file import path, and it is explicitly not introduced by this PR. The main product behaviors touched by this change area remained stable across functional, concurrency, and persistence scenarios, so current merge risk is low.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Parser	CREATE TABLE, INSERT, UPDATE, and DELETE all returned the expected PostgreSQL command tags and affected-row counts after parse and execution.
✅	—	Portal	Parse with ParameterOIDs=[0,0] completed, Bind accepted text values, INSERT returned CommandComplete INSERT 0 1, and readback confirmed the inserted row (id=2, qty=200).
✅	—	Portal	Re-parsing prepared statement prep_rapid with a new inferred parameter type executed against the latest query shape and returned the expected row without stale-plan/type errors.
✅	—	Query	The baseline SELECT path returned the two inserted employees in order and completed without protocol errors.
✅	—	Query	INSERT INTO employees_teams returned CommandComplete tag INSERT 0 2 with rows-affected=2 and no rowset payload, and follow-up SELECT confirmed both rows persisted.
✅	—	Schema	DROP SCHEMA guarded_schema was rejected because a dependent table existed, and both schema and table metadata remained intact and queryable.
✅	—	Schema	After dropping table clean_drop.t, DROP SCHEMA clean_drop succeeded and both schema and table metadata were removed from information_schema.
✅	—	Schema	Concurrent DDL operations targeting the same table name were serialized correctly, producing deterministic relation-exists errors without silent overwrite or data loss.
✅	—	Schema	Pre-restart schema and index mutations persisted, the server restarted cleanly, and post-restart reads plus additional INSERT/UPDATE/ALTER mutations all succeeded without root-value decode or serialization errors.
⚠️		Query	The system should reject unsafe file paths before file access, but COPY FROM file directly opens user-supplied paths and permits traversal-based reads/imports.

Additional Findings Details

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

⚪ COPY FROM file path traversal is not blocked

• Severity: Minor
• Description: The system should reject unsafe file paths before file access, but COPY FROM file directly opens user-supplied paths and permits traversal-based reads/imports.
• Impact: In some authentication query attempts, the flow can stall before fully completing and users may need to retry.
• Steps to Reproduce:
  1. Connect as postgres and create table copy_file_target(id int).
  2. Run COPY copy_file_target FROM '../../etc/passwd' WITH (FORMAT csv).
  3. Observe the error includes passwd text (for example 'root:x:0:0:root:/root:/bin/bash'), showing the file was opened and read.
  4. Create /tmp/traversal_test.csv and run COPY copy_file_target FROM '../../../../tmp/traversal_test.csv' WITH (FORMAT csv); observe rows are imported successfully through traversal.
• Stub / mock content: Authentication was intentionally bypassed in this QA run (EnableAuthentication=false), and the server ran with secure_file_priv set to an empty value; no mocks or route stubs were used for the COPY path itself.
• Code Analysis: In server/connection_handler.go, handleQueryOutsideEngine routes file-based COPY statements to copyFromFileQuery. That function contains TODOs for missing security and privilege checks and immediately calls os.Open(stmt.File), so user input reaches filesystem access without path sanitization or sandbox enforcement. A targeted fix is to enforce privilege checks and canonical path restrictions (for example, require an allowed base directory and reject paths that escape it) before opening the file.

Evidence Package

• text/QUERY-3/QUERY-3-copy-from-path-traversal.txt — 2 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18270	18270
Failures	23820	23820
Partial Successes1	5334	5334

	Main	PR
Successful	43.4070%	43.4070%
Failures	56.5930%	56.5930%

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]

This PR has been superseded by #2880