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

[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	2227.81/s	2198.20/s	-1.4%
groupby_scan_postgres	158.32/s	157.90/s	-0.3%
index_join_postgres	726.26/s	722.97/s	-0.5%
index_join_scan_postgres	948.48/s	946.51/s	-0.3%
index_scan_postgres	34.04/s	34.08/s	+0.1%
oltp_delete_insert_postgres	899.38/s	917.06/s	+1.9%
oltp_insert	832.82/s	837.27/s	+0.5%
oltp_point_select	3930.40/s	3989.73/s	+1.5%
oltp_read_only	3729.87/s	3754.75/s	+0.6%
oltp_read_write	2644.38/s	2792.89/s	+5.6%
oltp_update_index	848.15/s	869.86/s	+2.5%
oltp_update_non_index	918.41/s	942.57/s	+2.6%
oltp_write_only	1947.81/s	2044.91/s	+4.9%
select_random_points	2286.40/s	2299.43/s	+0.5%
select_random_ranges	1736.07/s	1738.33/s	+0.1%
table_scan_postgres	33.72/s	34.24/s	+1.5%
types_delete_insert_postgres	922.94/s	898.95/s	-2.6%
types_table_scan_postgres	14.57/s	14.97/s	+2.7%

[itoqa]

Commit: 7af28f6: 14 test cases ran, 12 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans core database behavior including startup and shutdown, persistence across restarts, catalog and metadata consistency, sequence and numeric handling, recovery after query errors, concurrent access, and clean versus cached builds. It exercises normal workflows alongside edge cases such as invalid input, existing data directories, type reporting, and concurrent requests, with overall application behavior healthy apart from two pre-existing defects.

Safe to merge — the failures are unrelated, pre-existing startup-safety and JSON metadata defects, with no regression or PR-attributable failure identified. They are flag-for-later observations rather than merge blockers for this dependency-only change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Catalog	The database list showed postgres and both new databases. Each database exposed pg_catalog, and the test table was available in both new databases.
✅	—	Catalog	Creating a sequence returned 10 first, setting it to 40 worked, and the next value was 42. Sequence details were also visible through the supported catalog views.
✅	—	Catalog	Adding and removing a database did not change the catalog schemas or table metadata in the remaining databases.
✅	—	Module	The project downloaded the new dependency from an empty module cache, verified its checksums, built the database server, and passed the core and SQL integration checks.
✅	—	Module	The cached and clean environments selected the same Dolt version and module graph. Both builds and the representative core and SQL tests passed, so the module cache did not hide a failure.
✅	—	Root	The custom mood type, its table, and the saved row were still available after the database was stopped and opened again.
✅	—	Root	The sequence, SQL functions, and trigger were still available after the server reopened. The sequence continued at 12, the function returned 42, and the trigger changed new rows as expected.
✅	—	Root	An invalid type query returned a controlled error, and valid queries continued to work in the same session, a second session, and after a restart.
✅	—	Startup	A new on-disk server started, accepted a database connection, returned the expected query results, and shut down cleanly.
✅	—	Startup	The in-memory server created and read a row, returned an error for an intentionally missing table, and then successfully ran a later valid query.
✅	—	Type	Explicit casts, assignments into typed columns, and mixed numeric expressions returned the expected values and types. Invalid decimal-to-integer input was rejected with a controlled error.
✅	—	Type	Eight database sessions resolved the same casts at the same time without errors. The values, result types, table rows, and catalog state stayed consistent after the concurrent work finished.
⚠️		Startup	The server did not reject a configured directory that already contained a .dolt directory. Instead, it reached the ready state and began creating the default superuser.
⚠️		Type	The json column returned data_type=jsonb and udt_name=json. The jsonb column returned jsonb/jsonb, so the standard data_type field does not preserve the declared type for json columns even though the values round-trip correctly.

Additional Findings Details

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

🟠 Existing data directory does not block startup

• Severity: High
• Description: The server did not reject a configured directory that already contained a .dolt directory. Instead, it reached the ready state and began creating the default superuser.
• Impact: When pointed at an existing database directory, the server starts instead of refusing to run. This can expose the existing database and make unwanted startup changes, such as creating a default user.
• Steps to Reproduce:
  1. Create a data directory that already contains a Dolt database, such as /tmp/doltgres-qa-existing-1/.dolt.
  2. Set DOLTGRES_DATA_DIR to that directory and start the persisted server with the normal command-line entrypoint.
  3. Check the startup output. The server reports "Server ready. Accepting connections." instead of returning the documented parent-directory rejection.
  4. Stop the process and confirm that startup did not fail immediately as expected.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The rejection is implemented in /tmp/output-agent-workspace/repo/server/server.go:90-97 inside runServer. At line 93, dEnv.HasDoltDataDir() is checked before the configured data directory is loaded. The command-line entrypoint creates dEnv from filesys.LocalFS at cmd/doltgres/main.go:214-216, so this initial environment is rooted at the process working directory. The configured directory is resolved separately by setupDataDir at cmd/doltgres/main.go:250-277; getDataDirFromParams reads DOLTGRES_DATA_DIR at lines 318-334 and stores it in cfg. Only later, at server/server.go:132-138, runServer changes the filesystem working directory to ssCfg.DataDir() and reloads dEnv. Therefore an existing .dolt directory below DOLTGRES_DATA_DIR is invisible to the earlier guard. The subsequent MultiEnvForDirectory call at server/server.go:142-149 can enumerate that configured directory, and the server continues into initialization rather than returning the safety error. The smallest practical fix is to perform the HasDoltDataDir check after loading the configured data directory, or to construct the initial dEnv against cfg.DataDir() before the check, while preserving the existing error path.

Evidence Package

• text/STARTUP-2/STARTUP-2-existing-directory-startup.txt — 2 KB

🟡 JSON columns show the wrong type

• Severity: Medium
• Description: The json column returned data_type=jsonb and udt_name=json. The jsonb column returned jsonb/jsonb, so the standard data_type field does not preserve the declared type for json columns even though the values round-trip correctly.
• Impact: Applications that inspect the database schema may treat a declared JSON column as JSONB, leading to incorrect schema handling or generated queries. Stored JSON values still work, and users can often work around the issue by checking the declared type directly.
• Steps to Reproduce:
  1. Create a table with both json and jsonb columns, then insert valid JSON values and a NULL row.
  2. Query the table and confirm that the stored JSON values and NULLs are returned correctly.
  3. Query information_schema.columns for the table and compare data_type with udt_name for the json column.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The production path is server/tables/information_schema/columns_table.go:304-312, where getDataAndUdtType sets udtName from dgType.Name() and derives dataType by converting the type ID through partypes.OidToType[...].SQLStandardName(). The parser implementation at postgres/parser/types/types.go:1511-1513 handles every JsonFamily type with an unconditional return of "jsonb" and comments that only binary JSON is supported. This conflicts with server/types/json.go:23-25, which defines a separate Doltgres type whose ID is "json". The smallest practical fix is to make SQLStandardName distinguish the json type from jsonb, or to special-case the json type at the information_schema conversion boundary, while preserving jsonb for the binary JSON type. The PR diff contains only go.mod line 9 and go.sum lines 249-250, which update the Dolt pseudo-version and checksums; it contains no changed production line in this metadata path, so the defect is not attributable to this PR.

Tip

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

[github-actions]

	Main	PR
Total	42090	42090
Successful	18908	18908
Failures	23182	23182
Partial Successes1	5325	5325

	Main	PR
Successful	44.9228%	44.9228%
Failures	55.0772%	55.0772%

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