Merged PRs

dolt

• 2023: global system var for sql-server session branch
  setting @@GLOBAL.dolt_sql_server_branch_ref overwrites the branch for new sql-server connections. Setting the variable does not change the current connection's branch. If the variable is set to an invalid ref (ex: branch does not exist), the behavior is undefined for new connections.

  > set GLOBAL dolt_sql_server_branch_ref = 'refs/heads/new'
  Query OK, 1 row affected (0.00 sec)
  mysql> select @@GLOBAL.dolt_sql_server_branch_ref;
  +-------------------------------------+
  | @@GLOBAL.dolt_sql_server_branch_ref |
  +-------------------------------------+
  | refs/heads/new                      |
  +-------------------------------------+
  1 row in set (0.00 sec)
  mysql> select active_branch();
  +-----------------+
  | active_branch() |
  +-----------------+
  | master          |
  +-----------------+
  mysql> exit
  Bye
  $ mysql --user root --host=0.0.0.0 -p tmp1
  mysql> select active_branch();
  +-----------------+
  | active_branch() |
  +-----------------+
  | new             |
  +-----------------+
  1 row in set (0.00 sec)
  

• 2021: Changed TEXT types to use BlobKind
  Previously we were using types.String at the noms layer to handle our TEXT types. This works for relatively small strings, but causes issues when using larger strings (such as a 2GB string). I'm not sure of the point at which performance tanks/crashes occur using types.String, but types.Blob can handle a string of arbitrary length (up to our allowed maximum of 4GB for sure). This also matches how our BLOB types are implemented.
  We do make use of the StringDefaultType variable all over the codebase, which was a LONGTEXT field. This has been changed to a VARCHAR(16383) field to preserve the expected behavior (passing in a types.String to the default string type for example). This does mean that our length limit is no longer 4GB, however I don't think we were ever reaching the VARCHAR limit to begin with, so this switch should be fine for all of our pre-existing logic. Additionally, the original string implementation remains (along with a LegacyStringDefaultType for system tables), so old repositories will continue to reference the old type as expected. This will only affect new tables. It was bad practice that we always used LONGTEXT to begin with.
  Our Go and bats tests make extensive use of LONGTEXT already (it was our only supported string type for a while), so minimal testing needed to be written.
  This PR also modifies types.Blob to properly sort, as previously it sorted by hash (which is the default for types that are an extension of sequence). Adding a proper Less function has broken some expected behaviors in noms for blobs, but they're not being used at all in Dolt, therefore it seems safe? Fixing these behaviors would entail a lower-level change, one which I didn't deem worth.
  Lastly, besides the large collection of small bug fixes here and there, I bumped the feature version. Any new tables that contain a TEXT type (of which there will probably be numerous) will be unable to be read by the previous version of Dolt (as they're missing the new blobStringType), and will throw an unknown error.
• 2006: disk backed edit accumulator

go-mysql-server

• 530: add engine tests for dateparse
  Follow-up to dolthub/go-mysql-server#523
• 529: Vinai/load file
• 523: implement built-in function str_to_date
  Closes #518
  This PR implements the STR_TO_DATE MySQL function.
  In places where the spec is ambiguous, I'm attempting to match the behavior of MySQL version 8 from my manual testing. I need to implement a few more parsers and add more test cases to cover the expected behavior.

  go test  -cover github.com/dolthub/go-mysql-server/sql/parse/dateparse
  ok  	github.com/dolthub/go-mysql-server/sql/parse/dateparse	0.163s	coverage: 89.3% of statements
  

  cc @zachmu

Closed Issues

• 1968: Add support for LOAD_FILE()
• 2002: [Bug] Simple inserts sometimes not saved
• 531: implement auto increment ddl support
• 518: Implement built-in STR_TO_DATE