Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bump
Created with
brew bump-formula-pr
.release notes
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 todolt 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
round()
handling of scale, precision, and nullsThis 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 ourDecimalMaxScale
(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
Correctness regression fix. With a bit more work this could probably be a smaller query:
charset
andcollate
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
Currently thecollate
option, even on binary columns.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 columnpk
. 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 forvarchar charset binary
. In fact, you're even allowed to writeCREATE TABLE t (pk varchar(10) collate binary);
and MySQL will generate avarbinary(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
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.
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.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 expectvarchar
.Closed Issues