This release contains backwards incompatible changes:

• The dolt_diff_<tablename> system table will log a SQL session warning and truncate historical values that are too large to fit in a modified schema. For example, if a varchar(100) column is changed to varchar(10), historical values larger than 10 characters will not be displayed in the dolt_diff_<tablename> system table and instead SQL warnings are logged and viewable with SHOW WARNINGS;. This change reverts a previous change (#6399) that changed the types of the dolt_diff_<tablename> system table, and was incorrectly released as a new patch version, instead of a minor version.

Per Dolt’s versioning policy, this is a minor version bump because column types for the dolt_diff_<tablename> system table have changed.

Merged PRs

dolt

• 6459: Log a SQL warning when historical values don't fit in dolt_diff_<tablename>'s schema
  We previously made a change (#6399) to automatically widen all columns in the dolt_diff_<tablename> system table to their widest setting (e.g. varchar(10) → TEXT), so that any historical values could still be displayed, even if the table's schema has been changed to a more restrictive/narrow type. This had an unintended side effect of changing data types for customers using the dolt_diff_<tablename> system table, even if they didn't have any schema changes in their table's history.
  Since then, I've investigated a few alternate approaches of how to handle this case. One idea was to search through the commit history, look for schema changes, and use the widest historical type for each column. This adds extra latency to all queries against the dolt_diff_<tablename> tables, since the commit graph has to be traversed an extra time before any results can be returned. It also turns out to be fairly involved to compare types – we don't have any APIs for that (yet) and there are some edge cases such as if a Decimal type is changed multiple times with various precision and scale that aren't all valid together.
  As that code got more complicated, I thought a simpler approach might be better to start with for handling this edge case where a historical value cannot be converted to the current table's schema. This PR applies the same behavior when a value can't be coerced to a type (e.g. trying to coerce a float to a geometry type) – it will truncate the value to NULL in the table and log a SQL warning in the session.
  This means that some historical values will be displayed as NULLs in the dolt_diff_<tablename> system table, which is still an improvement over the previous behavior where they would cause the query to error out and not return any result set. It also means that the column types will be the same types as on the current schema, making it easier for customer to know what type to expect in responses.
  We may still want to make this more sophisticated in the future, but this felt like a good tradeoff for now given that this edge case has not been a significant problem for customers so far.
• 6457: Create / alter table statements involving auto_increment columns now work
• 6440: Auto-merge schema changes that widen varchar columns
  Fixes #6261
• 6438: Implemented --prune for fetch command procedure
  dolt fetch --prune deletes any local remote refs that are not present on the remote being fetched. This is simpler than the equivalent git command, as it only operates on branches, not other kinds of refs.
  Fixes #6413
• 6390: Adds new --profile global arg
  Adds support for new --profile global arg which can group and apply a specified set of global args for the current command. Includes a new --profile flag and a new CLI command dolt profile to manage and list user profiles.

go-mysql-server

• 1925: Fix load data check constraint indexing bug
  fix show tests
• 1924: Makes several new kinds of alter table statements involving auto_increment columns work correctly
  Also: makes several kinds of ALTER TABLE statements with multiple clauses more lenient in their error checking than MySQL. These statements will now succeed instead of being rejected.
  Fixes #6218
• 1922: Render enum/set variables as strings after they are set
  Fixes #6370
  Ensure that when getting all session variables, if any of them is of an enum/set type, we convert them back to their string value. The SET command would amend the value in the session variables map to its numerical representation, which we need to translate back.
• 1921: Use a custom iterator when building HashJoin Lookups.
  Previously we were gathering all the child rows into a CachedResults node, and then iterating over the cached results to build the lookup. Cutting out the CachedResults and filling the lookup as we iterate simplifies the plan tree and also prevents a potentially large slice allocation.
  Benchmarking this showed no measurable impact on runtime, suggesting that the time taken populating/iterating over the cache was negligible. But the hash join used in the benchmark allocated 20% less memory.
• 1920: Allow AntiHashJoins to distinguish between empty and non-empty secondary tables.
  AntiHashJoin and LeftOuterHashExcludeNullsJoin should always evaluate at least one secondary row if the secondary table is nonempty. This guarentees the same behavior as MySQL for where x not in (...) expressions when x is nullable.
  Some joins (AntiJoins and some joins converted from AntiJoins) have an "excludes NULL" property, which means that if a filter condition on the join evaluates to NULL, the corresponding primary row can't be included in the result set.
  This means that if the primary row has a NULL value used in a filter, we need to know whether or not the secondary table has at least one row. Using a HashJoin makes that impossible without special handling.
  We had a test designed to catch this, but the test wasn't actually using a HashJoin, so this was missed. This PR also fixes the test to use a hash join.
• 1919: JSON_ARRAY correctly handles CHAR bindvar params
  The JSON_ARRAY function wasn't able to handle a []byte literal expression in a bind var. I also noticed that although our script tests can specify Bindings, they weren't getting used by our prepared query runners. I also fixed that, so that I could add a new test for this issue.
  Fixes: dolthub/go-mysql-server#1855
  Related Vitess change: dolthub/vitess#261
  Dolt CI Checks: #6441
• 1917: More name res tests
  Fix JSON_TABLE and stored procedures on new name resolution path.
  edit: Added on duplicate update rewrite
• 1914: More Full-Text fixes
  More bugs found and fixed for FULLTEXT indexes. The ordering bug is fairly major, as it could require a drop/readd of the index, so I want to get this out now rather than waiting until I've gotten more tests/fixes in.

vitess

• 261: Preserving bind var type for sqltypes.Char params
  When a caller executes a prepared statement, they send the parameters as well as parameter type information to the sql-server. Vitess populates bindvars type information that go-mysql-server uses to execute the query. Vitess is currently converting many SQL types to VARBINARY, including CHAR, which makes it look like binary data was sent and not a char string, like the caller indicated.
  This change stops converting sqltypes.Char bind var type info into VARBINARY, which enables go-mysql-server to see that a char string was passed. Without this type information, go-mysql-server doesn't seem able to differentiate between legitimate binary data sent by the client versus a character string. Since these types need to be handled differently, and we can't assume that all VARBINARY types can be converted into strings, it seems like we need to respect the SQL type the caller indicated for the bind var and pass that up to integrators.
  It seems like this change could be helpful for other SQL types, too, but I wanted to start with just sqltypes.Char to see if this approach causes any other issues.
  Fixes: dolthub/go-mysql-server#1855
  Related go-mysql-server PR: dolthub/go-mysql-server#1919
  Related Dolt PR: #6441
• 260: Rename MultiAlterDDL to AlterTable and return it for all ALTER TABLE statements
  This normalization makes it easier to handle building a plan

Closed Issues

• 6424: HASH_JOIN probe table copying perf
• 4130: Support LATERAL derived tables
• 6218: Can't add a new auto_increment column with a single alter statement
• 6370: SHOW VARIABLES should render enum/set values
• 6298: Slow Range Join
• 6261: Automatically merge changes that enlarge varchar fields
• 6413: Feature Request: analog of git fetch --prune to clean old branches
• 6429: Connect to a managed doltlab instance remote from local dolt repository
• 1855: GORM JSONArrayQuery.Contains isn't compatible