[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	2212.32/s	2207.68/s	-0.3%
groupby_scan_postgres	149.67/s	151.27/s	+1.0%
index_join_postgres	725.85/s	719.99/s	-0.9%
index_join_scan_postgres	931.54/s	917.47/s	-1.6%
index_scan_postgres	34.14/s	34.26/s	+0.3%
oltp_delete_insert_postgres	923.56/s	909.63/s	-1.6%
oltp_insert	835.82/s	858.96/s	+2.7%
oltp_point_select	3972.56/s	3961.49/s	-0.3%
oltp_read_only	3775.39/s	3749.60/s	-0.7%
oltp_read_write	2719.88/s	2793.95/s	+2.7%
oltp_update_index	878.88/s	873.62/s	-0.6%
oltp_update_non_index	939.96/s	942.49/s	+0.2%
oltp_write_only	1985.38/s	2044.86/s	+2.9%
select_random_points	2295.17/s	2284.74/s	-0.5%
select_random_ranges	1724.43/s	1723.22/s	-0.1%
table_scan_postgres	33.85/s	33.67/s	-0.6%
types_delete_insert_postgres	921.59/s	932.05/s	+1.1%
types_table_scan_postgres	14.95/s	14.69/s	-1.8%

[itoqa]

Commit: a551ef0: 13 test cases ran, 12 passed ✅, 1 additional finding ⚠️.

Summary

Coverage spans core database behavior, including startup and connections, data creation and updates, schema changes and persistence, indexing, branching and merging, foreign-key integrity, type conversions, and recovery after invalid operations. It includes normal workflows alongside edge cases such as rejected inputs, metadata consistency, restart behavior, branch-order differences, conflicting settings, and ancestor-less merges.

Safe to merge — the only failing behavior is a medium-severity, unrelated limitation in type-setting merges and ancestor-less merges, and no failure is attributable to this PR or indicates a regression. It is a flag for later rather than a merge blocker.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Cast	The database returned a clear error for invalid integer input, then kept the same type and table metadata. The session continued normally after the failed conversion.
✅	—	Cast	Numeric, string, domain, reverse-direction, and array expressions returned the expected PostgreSQL types. An unsupported integer-plus-text expression returned an operator error instead of silently coercing the values.
✅	—	Cast	After an invalid integer-plus-text operation, the catalog returned the same cast and column information in the current session and a new session.
✅	—	Dependency	Doltgres started with a fresh data directory, accepted a PostgreSQL connection, and returned 1 from a simple query in getting_started.
✅	—	Dependency	Explicit, assignment, and implicit casts returned the expected values. An unsupported text-to-number cast returned a clear error instead of producing a wrong value.
✅	—	Dependency	An invalid conversion failed only for its own request. The same connection recovered, and a new connection could still read the database, perform casts, and see the tables.
✅	—	Engine	The SQL service created employee and team tables, linked them with a foreign key, returned the joined row, changed John to Johnny, and removed the records successfully.
✅	—	Engine	Renaming the table, adding a column, and changing a column type all kept the table data and catalog metadata in sync. The changes were committed, survived a restart, and the old table name did not return.
✅	—	Engine	The database created a table and index, returned the expected rows for both lookup types, used the index in the query plan, and saved the updated amount without losing any rows.
✅	—	Merge	Different changes are classified as conflicts, and the merge keeps the values from both branches instead of silently dropping one.
✅	—	Merge	Both tested merge orders completed successfully. Equal values and one-sided rows were kept, with no conflict rows or leftover staged changes.
✅	—	Storage	The related tables, foreign key, catalog details, and Jane's row stayed together when the database switched branches and restarted.
⚠️		Merge	A branch merge with different type settings cannot reliably finish or report the conflict. The no-ancestor case can stop with an internal failure instead of keeping both sides available for resolution.

Additional Findings Details

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

🟡 Type merges can fail and lose conflict details

• Severity: Medium
• Description: A branch merge with different type settings cannot reliably finish or report the conflict. The no-ancestor case can stop with an internal failure instead of keeping both sides available for resolution.
• Impact: Merges involving conflicting type settings may fail instead of showing the conflict for resolution. Merges with no common ancestor may also stop with an internal error, leaving users unable to complete that merge.
• Steps to Reproduce:
  1. Create a base branch containing a custom domain or another type object.
  2. Create two branches and change independent type settings, such as the default and NOT NULL flag, on the two branches.
  3. Merge the branches and inspect the result and conflict metadata.
  4. Repeat with two type objects that have no common ancestor and inspect whether the merge completes without a server error.
• Stub / mock content: The target server was unavailable during the source-first remediation pass, and the recorded merge setup used local disposable test data. No application stubs, mocks, or route bypasses were applied.
• Code Analysis: The production path in core/typecollection/root_object.go:43-46 makes every type root-object diff fail immediately with errors.New("type conflict detection has not yet been implemented"). That prevents the merge framework from generating type conflict metadata for conflicting type objects. The separate handler in core/typecollection/collection_funcs.go:53-58 initializes ancType only when mro.AncestorRootObj is non-nil. For domain types, lines 68-77 pass ancType.Default to merge2.ResolveMergeValues, and lines 82-84 pass ancType.NotNull, before the resolver can use hasAncestor to distinguish an absent ancestor. When the ancestor is absent, those field evaluations dereference a nil *pgtypes.DoltgresType and can panic. The sequence implementation at core/sequences/collection_funcs.go:55-105 does have explicit resolvers for minimum, maximum, cache, cycle, data type, increment, start, current, and HasBeenCalled, so the confirmed defect is concentrated in type conflict handling and ancestor-less type merges rather than a blanket failure of all sequence-field merging. The smallest practical fix is to implement DiffRootObjects for type values and to supply safe zero/default ancestor field values, or branch before dereferencing ancType, for the no-ancestor domain path; then add focused tests for conflicting and ancestor-less type merges.

Evidence Package

• text/MERGE-3/MERGE-3-type-merge-failure.txt — 4 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18918	18918
Failures	23172	23172
Partial Successes1	5325	5325

	Main	PR
Successful	44.9465%	44.9465%
Failures	55.0535%	55.0535%

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. ↩