Merged PRs

dolt

• 7591: go/store/datas/pull: Revert puller changes from 1.34.0 until we investigate changes in resource utilization.
• 7584: fix comparison for []byte
  convert []bytes to string before comparing them
  companion pr (with tests):
  dolthub/go-mysql-server#2377
  fixes #7578
• 7581: fix bad charset tests and dolt table import schema
  recent charset changes exposed some issues with existing tests
  companion: dolthub/go-mysql-server#2376
• 7539: Feature: Schema overriding
  Allows customers to specify a commit, branch, or tag in the @@dolt_schema_override_commit session variable and have all table's data mapped to the schema from that commit, branch, or tag, when queried.

  Example

  As a simple example, consider a database with a main branch that has added the new column birthday to a table, and an olderBranch branch with a table that has not been updated with that schema change. Customers cannot use the same queries from the main branch to query the data on the olderBranch because of the schema difference. Setting a schema override allows the customer to map the table schemas on the olderBranch branch to the same schema as on the main branch. This can be useful when you want to run queries on older data, but don't want to rewrite your queries for older schemas.

  CALL dolt_checkout(‘olderBranch’);
  SELECT name, birthday from people;
  column "birthday" could not be found in any table in scope
  SET @@dolt_schema_override_commit = ‘main’;
  SELECT name, birthday from people;
  +-------+----------+
  | name  | birthday |
  +-------+----------+
  | Sammy | NULL     |
  +-------+----------+

  Limitations

  The first version of schema override support is subject to several limitations. Please reach out to us and let us know if you'd like any of these to be prioritized.
  • Read-only – when a schema override has been set, only read queries can be executed. Attempting to write data or execute DDL will result in an error about the database being read-only.
  • System tables – Dolt system tables currently do not honor schema overrides.
  • Collation changes – Collations affect how data is sorted when stored on disk. To map data from one collation to another collation requires extra processing to ensure the returned results are sorted according to the mapped collation. This extra processing is not supported yet, so collation changes will not appear when overriding a schema.
  • Column defaults – If the overridden schema has added new columns with column defaults, those column defaults do not currently get applied when that column is queried. Using the column default value, instead of NULL is a planned enhancement.
    Design doc
    Reference docs update: dolthub/docs#2062
    Fixes: #5486

go-mysql-server

• 2382: add support for json_pretty
  MySQL Docs:
  https://dev.mysql.com/doc/refman/8.0/en/json-utility-functions.html#function_json-pretty
• 2378: map straight join to inner join
  This PR temporarily remaps STRAIGHT_JOIN operator to INNER_JOIN operator.
  fixes #7580
• 2377: fix binary cast to maintain length
  We were improperly dropping CAST node during comparison.
  It might be fine in many cases, but it is definitely not for comparing BINARY column types.
• 2376: return errors for charset/collation mismatch
• 2373: charset table option tests
  In GMS, we reparse table options with a regular expression, but we only cover CHARACTER SET and not its synonym CHARSET.
  As a result, we just ignore table options for CHARSET.
  The fix is in dolthub/vitess#315
  TODO: maybe should just address this TODO instead...
• 2372: implement JSON_QUOTE()
  MySQL Docs:
  https://dev.mysql.com/doc/refman/8.0/en/json-creation-functions.html#function_json-quote
• 2371: don't use all caps for engines info table
  Some clients rely on the correct casing of column names
  For some reason, the casing is different when performing SHOW ENGINES; vs select * from information_schema.engines;
  Fortunately, the way we do SHOW ENGINES; is actually a SELECT ... under the hood.
  So the hacky fix is to just use an alias :)
  related #7574
• 2362: Feature: last_insert_uuid() function
  UUIDs are often used in place of auto_increment IDs, but MySQL doesn't provide an easy way to get the last generated UUID that was used in an insert. This change introduces a new function, last_insert_uuid() that operates similarly to last_insert_id(). For a column identified as a UUID column, callers can use last_insert_uuid() to retrieve the last generated UUID value that was inserted into that column. In order to be considered a UUID column, a column must be part of the primary key and it must meet one of the following type signatures:
  • VARCHAR(36) or CHAR(36) with a default value expression of UUID()
  • VARBINARY(16) or BINARY(16) with a default value expression of UUID_to_bin(UUID()) (optionally, the swap_flag for UUID_to_bin may also be specified)

  Example usage:

  create table t (pk binary(16) primary key default (UUID_to_bin(UUID())), c1 varchar(100));
  insert into t (c1) values ("one"), ("two");
  select last_insert_uuid();
  select c1 from t where pk = uuid_to_bin(last_insert_id());

  Related to #7547

vitess

• 315: support binary charset in table option
  This PR adds binary as a valid charset option.
  Additionally, this changes CHARSET to expand to synonym CHARACTER SET for parsing in GMS.
  fixes #7576
• 314: support casting to year

Closed Issues

• 5486: Ability to "project" schema at a commit onto data at another commit
• 7580: Support STRAIGHT_JOIN used by MediaWiki
• 7578: Panic on comparison in Query generated by MediaWiki.
• 7574: MediaWiki needs SHOW ENGINES to return first letter uppercase column names like MySQL
• 7576: default charset=binary is messing up in a create table statement
• 7568: Is too large for column error
• 7547: Feature suggestion: LAST_INSERT_UUID()

Performance