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

[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	1824.46/s	1817.53/s	-0.4%
groupby_scan_postgres	134.59/s	133.26/s	-1.0%
index_join_postgres	640.56/s	644.20/s	+0.5%
index_join_scan_postgres	785.32/s	781.36/s	-0.6%
index_scan_postgres	24.51/s	24.65/s	+0.5%
oltp_delete_insert_postgres	788.49/s	809.47/s	+2.6%
oltp_insert	692.48/s	691.04/s	-0.3%
oltp_point_select	2818.57/s	2855.14/s	+1.2%
oltp_read_only	2898.60/s	2853.96/s	-1.6%
oltp_read_write	2285.21/s	2300.48/s	+0.6%
oltp_update_index	712.83/s	723.82/s	+1.5%
oltp_update_non_index	748.64/s	732.56/s	-2.2%
oltp_write_only	1735.41/s	1731.77/s	-0.3%
select_random_points	1849.36/s	1814.23/s	-1.9%
select_random_ranges	1070.28/s	1063.02/s	-0.7%
table_scan_postgres	22.98/s	22.91/s	-0.4%
types_delete_insert_postgres	766.53/s	758.07/s	-1.2%
types_table_scan_postgres	7.96/s	7.85/s	-1.4%

[itoqa]

Commit: 072d58c: 5 test cases ran, 0 failed ❌, 4 passed ✅, 1 additional finding ⚠️.

Summary

Core database behaviors appear healthy, including client connection startup, session readiness, prepared-query execution, and repository read/write persistence across snapshot compatibility scenarios, reflecting strong happy-path and regression coverage for runtime data operations. Coverage also included a configuration edge case in authentication policy handling, with no indication that this PR changed that behavior.

Safe to merge — the exercised core connection, query, and storage flows were stable, and the only flagged issue is a medium-severity configuration behavior on an unchanged, pre-existing path rather than a regression from this PR. Overall merge risk for the current changes is low, with that auth-policy gap best tracked as separate follow-up work.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Engine	The extended PostgreSQL Parse -> Bind -> Execute flow completed successfully and returned the expected employee row (Ada Lovelace) without protocol errors.
✅	—	Startup	Startup authentication and session initialization succeeded with an explicit database and startup parameters, and the connection reached normal query-ready behavior.
✅	—	Storage	The repository opened without feature-version errors, all expected tables were readable, and write plus dolt_add/dolt_commit operations persisted successfully.
✅	—	Storage	Both prior repository snapshots opened successfully with the upgraded binary, returned expected table/query results, and showed no feature-version or decode errors in server logs.
⚠️		Config	Expected behavior differs by config value, but both runs produce the same authentication sequence and never request cleartext passwords.

Additional Findings Details

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

🟡 Cleartext password flag is unwired

• Severity: Medium
• Description: Expected behavior differs by config value, but both runs produce the same authentication sequence and never request cleartext passwords.
• Impact: Administrators cannot rely on the cleartext-password configuration toggle to enforce the intended authentication security posture, because both enabled and disabled settings behave the same. This can leave deployments with an unexpected auth policy on real client connections.
• Steps to Reproduce:
  1. Start the server with allow_cleartext_passwords set to false and attempt a non-TLS startup/authentication handshake.
  2. Restart the server with allow_cleartext_passwords set to true and repeat the same handshake.
  3. Compare the wire responses and inspect the authentication implementation for config call sites.
• Stub / mock content: The run used a non-production auth-bypass setup (authentication disabled for replayability) and switched between two local listener configs with allow_cleartext_passwords false vs true; this setup does not change the code finding that the flag is unwired in production auth logic.
• Code Analysis: In servercfg/cfgdetails/config.go, AllowCleartextPasswords is defined and has an accessor, but repository search shows no call sites outside that config file. In server/authentication_scram.go, handleAuthentication sends AuthenticationOk when auth is bypassed and AuthenticationSASL/SASLFinal otherwise, with no AuthenticationCleartextPassword branch. PR diff evidence shows only go.mod and go.sum changes, so this defect is on an unchanged production path.

Evidence Package

• text/CONFIG-1/CONFIG-1-auth-config-unwired-evidence.txt — 3 KB

Tip

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

[github-actions]

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

	Main	PR
Successful	43.4046%	43.4070%
Failures	56.5954%	56.5930%

${\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]

This PR has been superseded by #2872