Backwards Incompatible Changes

There has been a change in the way stashes are stored, so you may not be able to see stashes created before this version with dolt stash list. To update your stash references run the following commands on the command line:

dolt sql -q "call dolt_stash('pop', 'stashes')" to put your stashed changes back in the working set. Then run either of the following:

dolt stash or dolt sql -q "call dolt_stash('push', 'dolt-cli')"

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

• 9329: go: store/datas/database_common: store/nbs/store.go: Fix some issues when pushing to a dolt sql-server that is itself running GC. A push to a remote works by uploading the missing content and then adding references to it in the remote datastore. If the remote is running a GC during the push, it is possible for the newly added data to be collected and no longer be available when the references are added. This should cause a transient failure which is safe is retry. There were a couple bugs which could instead cause a panic. This makes some changes to safeguard against those case.
• 9317: go/store/nbs: archive_chunk_source.go: Make sure we skip getRecords marked found when fetching chunks. This avoids delivering the chunk more than once, which parts of the application layer are not expecting.
• 9310: tidy up errors This PR fixes index coll to use pointer receivers, and consolidates some errors to use the ones defined in GMS companion pr: https://github.com/dolthub/go-mysql-server/pull/3006
• 9309: go/store/nbs: Fix a bug where GetChunkLocations{,WithPaths} can return the same chunk more than once if it is in newgen and oldgen.
• 9308: dolt_stash stored procedure This Pr implements issue [#7623]. Includes the following changes:
• dolt_stashes system table to view current stashes. Currently read-only.
• dolt_stash() stored procedure to use in the server context. Must be given a specific command (push, pop, clear, or drop) and a stash name.
• 9301: Use 256 stripes in node cache
• 9270: Add dolt_preview_merge_conflicts table function This table function shows which rows are conflicting for a table between two branches. Will error if there are schema conflicts
• 9233: Add a dolt_preview_merge_conflicts_summary table function This table function shows which tables are conflicting between two branches and how many data and/or schema conflicts there are for each table

go-mysql-server

• 3021: Added test for insert...select...returning Fixes [#9248]
• 3018: fix text storage for left and instr function fixes: https://github.com/dolthub/dolt/issues/9322
• 3017: Support * in returning clauses part of [#9248]
• 3016: Minor updates to support UPDATE ... FROM in Doltgres Minor changes to support UPDATE ... FROM in Doltgres (https://github.com/dolthub/doltgresql/pull/1536) While working on this, I noticed a few issues with the UPDATE ... JOIN support in GMS:
• There was duplicated logic for UPDATE ... JOIN in PlanBuilder.buildUpdate() and in the analyzer rule modifyUpdateExprsForJoin. Not all UPDATE ... JOIN statements can be handled in PlanBuilder, because some statements, like IN SUBQUERY, are transformed into a join during analysis, so we need logic in the analyzer to identify UPDATE ... JOIN plans after that transformation. To reduce the duplication, I removed the logic from PlanBuilder and now we rely on on the modifyUpdateExprsForJoin rule to mark all UPDATE ... JOIN plans.
• Callers use plan.GetUpdatable() to get a reference to the table being updated, but UPDATE ... JOIN can update multiple tables. The GetUpdatable() APIs should be refactored to model this, otherwise we cannot accurately track multiple tables being modified and apply all the correct triggers/constraints.
• Currently UPDATE ... JOIN never honors foreign key constraints, due to limitations in the concrete type UpdateJoin.GetUpdatable() returns. The updatableJoinTable type does not implement sql.ForeignKeyTable, so GMS is unable to load any foreign key constraints from it. This also needs to be handled in a future PR.
• 3015: server var tests
• 3014: Simplify implementation of hasSingleOutput As part of adding support for IS NULL and IS NOT NULL implementations that can match Postgres's behavior for records, I've been digging through the references to expression.IsNull in GMS so that we can have a separate implementation for Doltgres that GMS can still analyze correctly. One reference to expression.IsNull is in the hasSingleOutput which is used to determine if an expression result has a single row or more than one row. The only expression implementation I was able to find that actually returns multiple rows is plan.Subquery, so I simplified this function to remove the reference to expression.IsNull.
• 3013: handle insert returning for server context
• 3012: Handle insert...returning... queries part of [#9248] insert...returning * currently doesn't work. Similar to dolthub/doltgresql#1432
• 3010: Add query time to logger This is a proposed fix for Dolt issue: https://github.com/dolthub/dolt/issues/8909 I'm not certain if we want to just add this field or replace connect time. I think this implementation is safer.
• 3006: implement if [not] exists logic for DDL around views and indexes This PR adds support for queries:
• create view if not exists ...
• create index if not exists ...
• alter table ... add index if not exists ...
• drop index if exists ... fixes: https://github.com/dolthub/dolt/issues/9293 companion pr: https://github.com/dolthub/vitess/pull/417

vitess

• 420: Make returning a reserved keyword Part of [#9248] Making returning a reserved keyword allows for returning clause in all types of insert statements
• 419: Add grammar support for insert...returning... (most cases) Part of [#9248] Insert...returning... statements work with insert_data_alias and SET assignment_list cases. The following examples (from the MariaDB documentation) work. INSERT INTO t2 (id) VALUES (2),(3) RETURNING id,t; INSERT INTO t1 SET id1=1, animal1='Bear' RETURNING f(id1), UPPER(animal1); I wasn't able to get insert...returning... to work with insert_data_select cases. The RETURNING clause is not supported for the following and would lead to a syntax error. INSERT INTO archive (id, data) SELECT id, data FROM live_data WHERE flag = 'old' RETURNING id; When I had added a RETURNING clause, there was a grammar conflict because the parser was not able to distinguish between a column alias and the 'RETURNING' keyword. This could be resolved by making RETURNING a reserved keyword, but we decided against that since RETURNING is a non-reserved keyword in MySQL (doc). I ran into a similar conflict with insert_data_alias cases because the parser was not able to distinguish between a table alias and the RETURNING keyword. This was resolved by adding RETURNING to non_reserved_keyword2. This means RETURNING can't be used as a table alias and may cause some customer issues but the likelihood is very low. Also removed TestSingle from parse_test.go (we already have TestSingleSQL)
• 417: add if not exists option to create view syntax for: https://github.com/dolthub/dolt/issues/9293 Introduced in MySQL 9.1: https://dev.mysql.com/doc/refman/9.1/en/create-view.html
• 416: New flavor of injected expression

Closed Issues

• 9337: Can't use LIKE together with JSON_TABLE
• 9332: remotesapi through reverse proxy (caddy) error
• 9248: support returning clause in inserts like mariadb ?
• 9322: Using LEFT on TEXT column fails with "invalid type: *val.TextStorage"
• 9090: Add sql function to determine "who is ahead"
• 9076: Unexpected type conversion in IFNULL
• 9293: IF (NOT) EXISTS does not work for some CREATE ...- and DROP-Statements
• 9312: csv import failed by "cause: cannot update manifest: database is read only"