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

[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	2211.42/s	2200.55/s	-0.5%
groupby_scan_postgres	156.01/s	153.62/s	-1.6%
index_join_postgres	716.24/s	712.33/s	-0.6%
index_join_scan_postgres	930.26/s	932.55/s	+0.2%
index_scan_postgres	34.06/s	34.09/s	0.0%
oltp_delete_insert_postgres	933.47/s	920.35/s	-1.5%
oltp_insert	795.01/s	805.53/s	+1.3%
oltp_point_select	3902.17/s	3805.38/s	-2.5%
oltp_read_only	3704.98/s	3674.40/s	-0.9%
oltp_read_write	2791.20/s	2731.33/s	-2.2%
oltp_update_index	856.50/s	868.37/s	+1.3%
oltp_update_non_index	927.12/s	931.00/s	+0.4%
oltp_write_only	1929.86/s	2016.01/s	+4.4%
select_random_points	2266.91/s	2250.53/s	-0.8%
select_random_ranges	1720.83/s	1709.30/s	-0.7%
table_scan_postgres	34.03/s	33.99/s	-0.2%
types_delete_insert_postgres	902.26/s	930.37/s	+3.1%
types_table_scan_postgres	14.98/s	14.81/s	-1.2%

[itoqa]

Commit: fc23dc9: 14 test cases ran, 11 passed ✅, 3 additional findings ⚠️.

Summary

Coverage spans core database behavior across persistence, restart and branch workflows, concurrent ID generation, database isolation, relationships, data types, session recovery, and schema metadata. It includes normal user flows plus edge cases such as concurrency, invalid references, unsupported types, legacy compatibility, and introspection behavior, with broad overall health despite several unrelated compatibility gaps.

Safe to merge — the failures are medium-severity, pre-existing product limitations and none are attributable to this PR, with no observed regressions or newly introduced failures. They are flag-for-later findings rather than merge blockers.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Sequence	A reset generated ID was saved, restored after restart, and followed by the next unique ID. The final rows used IDs 1, 2, 3, 101, and 102.
✅	—	Sequence	New connections continued the existing sequence values after a server restart. Branch handoffs kept ascending values at 16, 18, and 20, descending values at -3, -4, and -5, and generated a new SERIAL ID 4 without duplicates.
✅	—	Sequence	Forty concurrent inserts created 40 committed rows with 40 different IDs from 1 through 40. After the server restarted, the next insert received ID 41 and the final 41 rows still had unique IDs.
✅	—	Session	Current-database queries returned only the tables from the active database, and an explicit lookup returned only the requested database's table. Switching from alpha to beta did not expose alpha's data.
✅	—	Storage	After the server restarted with the same data directory, all three tables, the saved employee-to-team row, and both foreign-key links were still available.
✅	—	Storage	The compatibility check was blocked by a missing old-format database fixture, not by an application error. The repository regression test covers loading a root without this field, saving an update, and reading it back successfully.
✅	—	Storage	Merging the feature branch kept all four tables, their three foreign keys, and the new project row available on the main branch.
✅	—	Storage	The branch merge kept the parent and child tables together with their foreign key. A valid child row remained available after restart, and an invalid parent ID was rejected.
✅	—	Type	The database kept numeric values, binary data, JSON documents, and transaction IDs unchanged after a restart. Column information remained readable, so this compatibility check passed.
✅	—	Type	An unsupported type definition returned a normal error instead of crashing the server. The same connection and a second connection continued to create, query, and inspect ordinary data.
✅	—	Type	Numeric precision, casts, JSON, binary data, strings, and transaction IDs matched after the database restarted and after the data was read from a branch.
⚠️		Session	The function call fails with an internal output error. The expected record rows are not returned, even though the table, sequence, type, and function were created successfully.
⚠️		Type	The bounded column accepts the expected 12-character value, but the catalog gives both the bounded and unbounded columns the same value, meaning no length limit. The information schema still reports 12 for the bounded column, so the stored type information exists but is not exposed consistently by pg_attribute.
⚠️		Type	The enum rows persisted and the feature table was correctly isolated from main, but format_type returned ??? for mood. PostgreSQL clients expect this metadata function to return the user-defined type name.

Additional Findings Details

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

🟡 Set-returning functions fail during output

• Severity: Medium
• Description: The function call fails with an internal output error. The expected record rows are not returned, even though the table, sequence, type, and function were created successfully.
• Impact: Users who call a function that returns record rows receive an internal database error instead of the expected rows, so that query cannot complete.
• Steps to Reproduce:
  1. Create a user-defined composite type and a function that returns a table or a set of records.
  2. Call the function with a SELECT statement.
  3. Observe that the query fails with an unexpected output-type error instead of returning the record rows.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run. The test used a local Doltgres instance and locally created SQL objects.
• Code Analysis: The captured SQL result reports unexpected type for io output, expected string, got []types.RecordValue when the created function is invoked. This is consistent with the production path in server/functions/record.go:52-64, where record_out accepts []pgtypes.RecordValue and returns pgtypes.RecordToString(ctx, values), while server/types/type.go:724-751 calls the output function and then unconditionally unwraps its result as a string. The failure occurs when the record output path returns a []RecordValue value to IoOutput rather than the string expected by the unwrap. The smallest practical fix is to make the record output adapter and IoOutput agree on the representation used for composite results: either ensure record_out returns the final string through the registered function path, or handle the record value returned by that path before the string unwrap. The synthetic-database isolation code itself is source-supported: core/context.go:96-132 returns a shared empty root for databases without a Doltgres RootValue, and core/context.go:314-344 caches collections by the selected database, preventing user collections from being loaded into that empty root. Runtime re-execution of the synthetic database portion was blocked by unavailable local infrastructure, but that limitation does not explain the independently captured function output error.

Evidence Package

• text/SESSION-2/SESSION-2-function-output-and-isolation.txt — 3 KB

🟡 Bounded string metadata is lost

• Severity: Medium
• Description: The bounded column accepts the expected 12-character value, but the catalog gives both the bounded and unbounded columns the same value, meaning no length limit. The information schema still reports 12 for the bounded column, so the stored type information exists but is not exposed consistently by pg_attribute.
• Impact: Clients that inspect table metadata cannot tell bounded strings from unbounded strings. Stored values and length checks still work, and clients can use the information schema as a workaround.
• Steps to Reproduce:
  1. Create a table with one varchar column and one varchar(12) column.
  2. Insert a 12-character value into the bounded column.
  3. Query pg_attribute for both columns and read the type modifier metadata.
  4. Compare that result with information_schema.columns.character_maximum_length.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The local SQL reproduction is consistent with the production code path. In server/tables/pgcatalog/pg_attribute.go, cachePgAttributes builds each pgAttribute from the schema's column type but stores only the type OID in the pgAttribute struct (lines 96-130); the struct has no field for the type modifier (lines 407-419). pgAttributeToRow then returns int32(-1) unconditionally for the atttypmod column at line 470, so every catalog row claims that no type modifier exists. This is not a string parsing or value-storage problem: server/types/varchar.go creates a bounded type with NewVarCharType, computes the PostgreSQL modifier as maxChars+4, and copies it into attTypMod via WithAttTypMod at lines 78-86 and 108-110. The wire result path in server/doltgres_handler.go already reads GetAttTypMod at line 541, showing the type object carries the modifier correctly in another metadata response. The smallest practical fix is to retain the column type's GetAttTypMod value when constructing each pgAttribute (and for analyzed view columns), add that field to pgAttribute, and return it from pgAttributeToRow instead of the hardcoded -1. The PR diff contains only go.mod and go.sum dependency version changes, so it provides no changed line that caused this defect.

Evidence Package

• text/TYPE-2/TYPE-2-bounded-string-metadata.txt — 3 KB

🟡 Custom type names are missing from metadata

• Severity: Medium
• Description: The enum rows persisted and the feature table was correctly isolated from main, but format_type returned ??? for mood. PostgreSQL clients expect this metadata function to return the user-defined type name.
• Impact: Applications and schema tools that inspect user-defined enum types may see an unknown type marker instead of the real name, causing incorrect schemas or lost type information even though enum data can still be stored and read.
• Steps to Reproduce:
  1. Create an enum type named mood with values such as sad, ok, and happy.
  2. Create a table using mood, insert a row, commit it, and create a feature branch with another table using the same enum.
  3. Query pg_type for mood and call format_type(t.oid, NULL) for that type.
  4. Check out the main branch and confirm that the feature-only table is absent while the enum data remains readable.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run. The check used a local Doltgres SQL server with a temporary database and branch fixture.
• Code Analysis: The failure is directly explained by server/functions/format_type.go:34-51. The registered format_type function converts the supplied identifier to an OID, looks it up only in the static types.OidToType map at lines 42-43, and returns the literal string ??? at lines 49-50 whenever that lookup misses. User-defined enum OIDs are created at runtime and are not entries in that built-in OID map, so the observed mood OID takes the fallback path even though the enum exists and its values are usable. The type implementation in postgres/parser/types/types.go:1594-1596 can format a hydrated enum as t.TypeMeta.Name.Basename(), but server/functions/format_type.go never obtains the runtime type object for this path. A targeted fix is to resolve non-built-in OIDs through the current database's type catalog before returning the fallback, then call the existing type-name formatting logic; the fix should preserve the existing ??? behavior only for genuinely unknown OIDs.

Evidence Package

• text/TYPE-3/TYPE-3-custom-type-metadata.txt — 2 KB

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18940	18940
Failures	23150	23150
Partial Successes1	5340	5340

	Main	PR
Successful	44.9988%	44.9988%
Failures	55.0012%	55.0012%

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