Merged PRs

dolt

• 9208: When a table is deleted on one branch and has its data modified on the other, record this as a schema conflict.
  Currently, attempting to merge when a table has been drop on one branch and had its data modified on the other produces an immediate error that aborts the merge. This error does not necessarily have enough context to determine the affected table, which makes resolving the merge difficult.
  Given that we already handle a simultaneous drop + schema modification (by treating it as a schema conflict), we should be able to handle the simpler case of data modifications as well.
  Since dropping a table is technically a schema change, this should now get reported as a schema conflict, and pause the merge, allowing the user to query dolt_schema_conflicts for more information.
  After this PR, conflicts involving a dropped table will present the same as other schema conflicts: the user still won't be able to use dolt conflicts resolve to resolve them because of #6616, but the user can query dolt_schema_conflicts to see the cause of the conflict.

go-mysql-server

• 2974: fixval.TextStorage panic
  fixes: #9202
• 2973: implement quote
  MySQL Docs: https://dev.mysql.com/doc/refman/8.4/en/string-functions.html#function_quote
• 2972: make bit type columns with default values round trippable
  fixes: #9194

vitess

• 402: add variable to colval
• 388: syntax for FLUSH TABLE
  MyDumper expects this syntax to at least parse.

Closed Issues

• 7841: Add support for ALTER USER ... WITH <resource option>
• 9201: Selecting from view using AS OF errors if the view doesn't exist on the current branch
• 9202: Querying longtext with WHERE IN results in panic: interface conversion: interface {} is *val.TextStorage, not string
• 9194: Round Trip tables with bit(...) type and DEFAULT value

Performance