Merged PRs

dolt

• 7191: Correctly resolve merge conflicts for types where two values with different representations can compare equal.
  Prior to this PR, we used the column's comparison operator when attempting to detect if concurrent changes to a column could be resolved during a merge operation.
  However, this can cause a problem when a type has two different representations that compare equal.
  • Some types have different representations that compare equal but can exhibit different behavior. For example, strings in a case-insensitive text column compare equal but behave differently when used in a context with a different collation and when displayed to the user. In this case, the merge algorithm should not consider them equal.
  • Other types have different representations that compare equal and exhibit identical behavior. For example, we store Decimal types as a (integer, exponent) pair, but we don't normalize this pair. So pairs like (45, 1), (450, 0), and (4500, -1) are all indistinguishable, including comparing equal. Since there's no way to distinguish these and the user should not have to know or care which representation is used, there is no danger in resolving potential merge conflicts by simply choosing a value. However, care must be taken that the same value is used regardless of the direction of the merge, in order to guarentee that the final table hash is the same.
    In order to accomplish both of these, this PR does two things:
  • Forces the three-way merge algorithm to use a default comparator instead of the table's comparator. This defaults to a binary collation for strings.
  • In the event that a merge conflict is auto-resolvable because the two values being assigned are equal to each other, sort them and use the higher one instead of choosing one branch arbitrarily.
• 7181: Warning for nonsense variables in config
  Prints a warning if any nonsense variables are found in global or local config files whenever any CLI command is run. Also restricts users from adding any nonsense variables with dolt config --add or dolt config --set.
  Resolves: #7165

go-mysql-server

• 2210: sql/planbuilder: Update join defaults are not prefixed, need individual table schemas to resolve
  Updates need to resolve default expressions. The input definitions for update joins include the total join output columns. If two of those columns have the same name, the target table's unqualified default expression will throw an "ambiguous column" error. We partition the update join schemas/column definitions to sidestep the error.
  The case where this is problematic is ALTER COLUMN expressions, where only the columns being modified are scoped for some reason. In those cases, I create a new scope with the source table schema to provide the full set of underlying column definitions. There is probably a whole class of virtual columns/column default bugs related to the way we resolve alter statements.
• 2206: guard ctx.Span again
  dolthub/go-mysql-server#2203 again, because it was overwritten
  fixes #7182 again
• 2205: use entire lateral scope when indexing RangeHeapJoin
  RangeHeapJoins looked at the lateral join scope when assigning indexes.
  However, we never tested nested joins for this case, leading to #7177
  What made the error more apparent was the string in the left scope that would result in empty results when doing lookups into the right tables. The fix was to look at the whole lateral scope when indexing RangeHeapJoins
  fixes #7177
• 2188: support on update current_timestamp
  This PR adds support for handling and executing ON UPDATE column expressions, which are triggered when an update is applied to any column in the row.
  TODO:
  • we support now() for default, but not the syntax for on update
    fixes #6030

vitess

• 295: Allow inline column check constraint definitions to appear in any order
  Previously, an inline column check constraint could only appear as the very last option for a column definition. This change allows it to appear in other positions in the column definition. For example, this query now works:

  create table t123 (c1 varchar(5) check (c1 in ('v1', 'v2')) NOT NULL);

  Resolves: #7195
• 294: Allow SqlType to parse "CHARACTER" and add tests for every other possible type that could be passed in.
  SqlType is a function in Vitess for normalizing every type name. It was missing an entry for the "CHARACTER" keyword.
  I added tests that should verify every single valid type keyword in the grammar, so this shouldn't happen again.

Closed Issues

• 7195: Error parsing CREATE TABLE with both CHECK and NOT NULL
• 7080: Joins against columns with case insensitive collations sometimes compare the join condition as if they were case sensitive.
• 7177: Query results are not as expected
• 7165: Fail when there is nonsense in config_golbal.json
• 7186: Support SET PERSIST GLOBAL for Dolt system variables