Merged PRs

dolt

• 6781: /go/utils/publishrelease/buildbinaries.sh: fix golang tag;
• 6777: go/go.mod: Require Go 1.21 in our go.mod.
• 6767: go: sqle: cluster: Improvements for DROP DATABASE replication. Fix a bug in session handling for the replication api endpoint which would prevent a dropped database from being recreated on a replica. Fix a race condition when a database is recreated after it is dropped. In that case, we stop attempting to replicate the drop, so that it does not replicate after the new database does.
• 6764: update fetch context handling Updates fetch context handling to properly exit with an error if force cancelled.
• 6738: migrate dolt push to use sql queries This change updates dolt push to use the appropriate sql engine to generate results. Related: https://github.com/dolthub/dolt/issues/3922
• 6703: When a three-way merge contains an altered column, convert values to the new column type in order to prevent conflicts. Fixes https://github.com/dolthub/dolt/issues/6660 I thought this was going to be a simple tweak, but it turns out that three-way merges in the presence of altered columns has some interesting subtleties. First off, we don't just compare the bytes of cells when merging, we actually de-serialize them and check for equality. I suspect this doesn't matter in most cases, but is done because:
  • Some types may have multiple ways to represent the same value, and
  • In the event of an altered column, two distinct values (of different types) may have the same representation. This leads to some subtle edge cases: for example, if once branch alters a column type, and then modifies a row so the cell as the same representation as the original, unaltered value, we still need to detect that as a modification, otherwise we might silently drop it during the merge. On the other side of the coin, if one branch alters a column and the other branch modifies that column, that's not necessarily a conflict even though the representations of both cells have changed. The logic for merging cells is more complicated now than it was before, but I added comments that should make it easy to follow. In brief, we detect when columns have been altered and convert values as appropriate before checking to see if they've been modified by the branch. In slightly more detail, if we have a cell with value base (of type A), a branch right which alters the column to have type B, and a branch left which modifies the cell (but is still type A):
  • We convert base to type B in order to detect whether the branch right also modified the cell.
  • We also convert the value on left to type B in order to detect whether a conflict exists with the value on right. I'm still writing extra tests, and the Convert method doesn't support every type yet, but the design is ready for feedback.

go-mysql-server

• 2060: Fixed various bugs in last_insert_id Fixes https://github.com/dolthub/dolt/issues/6776 Also adds better test coverage for LAST_INSERT_ID() and the INSERT_ID field in the ok response for updates.
• 2059: fix db qualified column names in order by We did not handle the case where database qualified column names would be in the order by clause. This PR fixes that issue and adds a variety of tests with database qualified column names and database qualified table names. There is still a case where joining two tables with the same name from two different databases results in an error; there's a skipped test for this, and a workaround is to alias the tables. fixes https://github.com/dolthub/dolt/issues/6773
• 2054: prevent projections to be pushed past lateral joins pruneTables will pushdown projections as low as possible to avoid passing around columns that won't make it to the final result. In the case of lateral joins, a column that isn't referenced in the topmost projection may still be referenced by subqueries, which causes problems. This PR prevents the projection pushdown optimization from applying to the children of lateral joins. A better solution might be to determine which columns are referenced, and trim out all others. However, that seems hard. fixes https://github.com/dolthub/dolt/issues/6741
• 2051: Trigger view errors don't prevent writes on database with preexisting trigger views PR https://github.com/dolthub/go-mysql-server/pull/2034 made it so that we can not DDL triggers on views. But past versions of Dolt permitted creating those triggers. After this change, databases with a trigger view will be have all writes blocked with the trigger view error. We should probably not try to parse and bind all triggers for every write, but as long as we do this adds a warning rather than an error for a non-DDL trigger parse.
• 2050: Fix binding of time.Time via driver When using the driver in v0.17.0, an error occurs when binding a variable of type time.Time as a query parameter. The error message looks like this:

  type time.Time not supported as bind var: 2023-10-01 17:37:49.382855116 +0900 JST m=+0.017340108
  

  This issue did not occur in v0.16.0. While it's possible to resolve this by modifying sqltypes.BuildBindVariable() in vitess, this PR resolves it within the driver itself by converting the variable into a timestamp literal string.
• 2049: adding gosql prepared tests We are lacking in tests that use the gosql driver to connect and run queries against an in-memory GMS server. This PR creates a new test suite so it's easier to write these tests. Additionally, there are some tests targeting a bug involving unsigned integers being read as signed.
• 2048: Prevent identifiers longer than 64 characters Also fixed a bug where we allowed multiple column names with the same case-insensitive name Fixes https://github.com/dolthub/dolt/issues/6611

Closed Issues

• 6776: SELECT LAST_INSERT_ID() returns BIGINT SIGNED for BIGINT UNSIGNED ids
• 6773: Column could not be found when using fully qualified table name in ORDER BY
• 4798: Table functions need unique names in queries, like tables
• 6195: Error resolving union'ed recursive CTE query
• 6660: Dolt revert panics after changing column from VARCHAR to TEXT
• 6194: LATERAL joins
• 6758: SECURITY ERROR v1.70.x
• 6741: LATERAL join bugs

Latency