This release contains backwards incompatible changes:

• The dolt_merge() and dolt_pull() procedure output schemas have changed (documentation). Each procedure has an additional column named message which is an optional field intended for human readable information.
• Merge behavior for changes which are already in the reachable history from HEAD previously would result in new merge commits. (issue). This is unexpected behavior, and deviates from Git. Now when this occurs dolt_merge() and dolt_pull() will return without any updates to the commit history. As this is not an error, we opted to use the message column to communicate to users what occurred.

Per Dolt’s versioning policy, this is a minor version bump because these changes may impact existing applications. Please reach out to us on GitHub or Discord if you have questions or need help with any of these changes.

Merged PRs

dolt

• 7363: dolt merge noop fix
  dolt_merge() operation now appropriately ends as a no-op when an attempt is made to merge in a commit which is already reachable from HEAD. This matches git behavior, and is a non-error scenario.
  In order to communicate to users what actually happened, the message column was added to the output of dolt_merge() and dolt_pull() stored procedures. Given the change in schema and that some user may actually depend on this broken merge behavior, this is a breaking change.
  Fixes: #7344

go-mysql-server

• 2274: Fixup index selection when prefix not complete
  Consider a query SELECT * from t where b = 1 and c = 1 and two indexes, (a,b,c) and (b,c). We want to use the (b,c) index as a lookup, because (a,b,c) will be disjoint on an (b,c) key. This PR fixes index costing to record and prefer non-zero prefix matches. We only differentiate zero and non-zero cases here because it is easier and I think pretty reliable.
• 2273: Add support for the ALTER USER statement to change account passwords
  Adds basic support for the ALTER USER statement, so that users can change passwords. All users are allowed to change their own password; changing another user's password requires the CREATE USER privilege or the UPDATE privilege on the mysql database.
  MySQL reference docs for ALTER USER
  Related to: #7348
• 2248: Use DESCRIBE ANALYZE / EXPLAIN ANALYZE to display stats data about joins.
  (In MySQL, DESCRIBE and EXPLAIN are aliases. GMS pretty consistently uses DESCRIBE internally, so I prefer that here.)
  This PR has a couple different pieces:

  sql.DescribeStats

  The most important part of this PR is the mixin struct sql.DescribeStats, defined in sql/describe.go. By embedding this struct within a Node or Expression, the node will store information about the cost estimate and row count estimate of the plan that was used to generate the node. This information can then be included in the Node/Expressions's string representation by calling the method DescribeStats.GetDescribeStatsString.
  Currently, only Join nodes embed this mixin.
  There's two ways to surface this information during a query.
  1. DESCRIBE format=estimates SELECT ... will include the row estimates and cost estimates of every node that supports this.
  2. DESCRIBE ANALYZE SELECT ... will execute the plan, and then display the actual row counts alongside the estimates.
     Note that DESCRIBE ANALYZE is only permitted for queries that don't have side effects. For instance, DESCRIBE ANALYZE INSERT ... will fail with an error.

  sql.Describable

  Previously, each Node or Expression had two different string representations, implemented as String() and DebugString(). DESCRIBE could emit either by using format=tree (the default) or format=debug. This isn't really a scalable solution, and the number of levers we want to control plan formatting may increase further over time.
  So this PR also adds a new interface for controlling how plans trees are displayed: sql.Describable. It has one method: Describe(options sql.DescribeOptions) string. DescribeOptions is a struct that contains all options that control how plans are displayed, and more options can be added as needed.
  These options are set via the value of the format= parameter in the describe query, which now accepts an underscore-separated list of options. Eg, format=debug_estimates.
  When writing the string representation of a node with children, you should call sql.Describe(node, options) instead of calling node.String() or sql.DebugString(node). This function calls Describe on the node if it exists, and otherwise falls back on DebugString or String. This allows for incremental support of the sql.Describable interface as needed instead of needing to add support for every node type right out of the gate.

  How to add support for additional node types

  While only Join nodes are currently supported, it's very easy to add support for other types. Literally all you have to do is embed the sql.DescribeStats struct in the node, and implement the Describe method, like so:

  type DemoNode struct {
  sql.DescribeStats,
  ...
  }
  func (d DemoNode) Describe(options sql.DescribeOptions) string {
  p := sql.NewTreePrinter()
  _ = p.WriteNode("Demo")
  _ = p.WriteChildren(sql.Describe(d.Child, options))
  return p.String()
  }

  Testing

  In order to test this functionality, every plan test generated by plangen.go now has three different expected plans: One for debug strings, one for debug + estimates, and one for debug + estimates + analyze.
  This may turn out to be too noisy when we make changes to the coster, but the plan tests are already noisy wrt to costing changes. If this turns out to be too much of a hassle we can limit this to just query_plans.go instead of all the plan tests.

Closed Issues

• 7344: dolt_pull creates unnecessary merge commits if the local branch is only ahead
• 2184: GolangCI does not work