dolt 1.29.2

[BrewTestBot]

Created by brew bump

---

Created with brew bump-formula-pr.

release notes

# Merged PRs
dolt


7122: Add support for -B flag to dolt_checkout
Resolves Issue: Dolt Checkout: -B Support dolthub/dolt#7116


7105: Add of out date warning to dolt version

Adds an out of date warning to dolt version if not using the latest release.

Also adds docs and help text for dolt version.

Resolves: dolt version should tell me when I'm out of date dolthub/dolt#3417


go-mysql-server

2189: Upgraded xxhash to v2
2187: fix round() handling of scale, precision, and nulls

This PR has ROUND() behavior match MySQL more closely specifically when handling NULLs.

Additionally, it refactors the function to no longer use custom logic, and rely on decimal.Decimal library for conversions.

The slowness from the original issues stems from the math.Pow() function that is attempting to raise precision to some huge negative number. This PR solves that problem by constraining the precision values to our DecimalMaxScale (30).

A better constraint would be -308 since that's the max scale of a float supported by MySQL. However, we don't go nearly as far. If we knew the scale of the passed in value we could also constrain the precision that way.

This PR also rewrites the ROUND() unit tests to be structured like other unit tests for functions, and fixes their handling of null arguments.

fixes: Potential Issue Using ROUND dolthub/dolt#7073
2182: fix IN_SUBQUERY projection bugs

Correctness regression fix. With a bit more work this could probably be a smaller query:
CREATE VIEW view_2_tab1_157 AS SELECT pk, col0 FROM tab1 WHERE NOT ((col0 IN (SELECT col3 FROM tab1 WHERE ((col0 IS NULL) OR col3 > 5 OR col3 <= 50 OR col1 < 83.11))) OR col0 > 75);
The CREATE panicked because the top-level projections get pushed into the source node, and my recent refactors failed to map projections onto the reported table output column sets.
2178: Improve handling of charset and collate in column options.

Add additional types to sqlparser.SQLType() dolthub/vitess#293 should be merged before this.

This PR does two main things:
Parse and validate the collate option, even on binary columns.
Currently the collate option is ignored on columns of binary type, an we just assume binary collation because it's the only one allowed. This is usually correct but causes some problems.

CREATE TABLE t (pk varbinary(10) collate utf8mb4_0900_bin); shouldn't parse, because it's attempting to use an illege collation for column pk. However, we currently ignore the option and parse it anyway.

CREATE TABLE t (pk varbinary(10)) collate utf8mb4_0900_bin; on the other hand, needs to succeed. Binary columns do not inherit the default collation of the table.
Reject the charset option except on columns that allow it.
According to MySQL, only text, sets, and enums are allowed to have character sets. Attempting to specify a character set for any other column type is an error. Before this PR, we were simply ignoring the character set where it didn't make sense.

A good way to think of it is that varbinary is like a shorthand for varchar charset binary. In fact, you're even allowed to write CREATE TABLE t (pk varchar(10) collate binary); and MySQL will generate a varbinary(10) column. Since the column already has a specified char set, it doesn't default to the table charset/collation. And you can't supply an explicit charset to the column because it already has one implicitly.

vitess

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.
293: Add additional types to sqlparser.SQLType()

This function is used when the parser needs to map type names to underlying types in order to judge the validity of certain queries. Some types are aliases for others, (like REAL is an alias for float64) but they weren't included in SQLType(), so certain expressions that used these types could panic.
292: Parse COLLATE BINARY on individual columns.

We should be able to parse statements like:

create table test (pk varchar(255) collate binary)

This particular example will eventually get rewritten as create table test (pk varbinary(255)), but that doesn't happen during parsing, so the added vitess tests still expect varchar.
291: round trip SHOW PLUGINS

Closed Issues

3417: dolt version should tell me when I'm out of date
7121: dolt init freezes under windows with 1.29.0

[github-actions]

🤖 An automated task has requested bottles to be published to this PR.