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
NOT
expression in conjunction withWHERE EXISTS(<subquery>)
The analyzer rule
unnest_exists_subqueries
was accidentally droppingNOT
expressions when hoisting subqueries fromWHERE EXISTS...
clauses.This should fix 8 sqllogictests.
Correctness: bump dolthub/dolt#7510
DISTINCT
overDECIMALS
There was another place where we were using
hashstructure
package, which does not hashdecimal.Decimal
types correctly.Switched to
xxhash
package, which is what we use everywhere else.Reusing solution from: fix count distinct with decimals dolthub/go-mysql-server#2279
This will fix 1 sqllogictest.
expression.Div
Micro BenchmarksThere are going to be changes to our division behavior that impact both its accuracy and speed.
This PR adds benchmarks to track the runtime improvements/degradations
This PR has a variety of fixes to have arithmetic operations (especially those involving decimals) behave more like MySQL.
The logic for the
Type()
method forArthmetic
andDiv
is simpler, and better tested.When comparing Decimal results from division operations, MySQL has an internal Scale that is different than the Scale used when returning Decimal results for display.
Here's a matrix displaying the resulting scale:
(Ex:
1 / 3 = 0.333333333
; scale 0 div scale 0 should return scale 9)Additionally, this PR adds test for arithmetic operations over Datetime and Year types. There are still a some problems dealing with precision and parsing there...
Note: I believe the division optimization where float division is preferred over decimal division for internal calculations may be causing problems. More testing is needed to see if it's possible to enable this without causing inaccuracies/precision loss.There are microbenchmarks measuring the performance of div expression, and it turns out these changes actually greatly improve the runtime.
Correctness: bump dolthub/dolt#7484
Fixes
We originally supported one type of procedure handler,
NOT FOUND
, which explicitly checked for an error when fetching from a cursor io.EOFs. The implementation for that handler would walk the entire BEGIN/END scope stack inside the Fetch call looking for a handler, execute the handler body, and then embed the scope height into a special return error. The error walked back up the callstack looking for the BEGIN/END block embedded in the error message.This PR:
FetchEOF
, because each scope will explicitly compare its handlers to errors raised during execution within its BEGIN/END bounds. (FetchEOF
is important because we differentiate between 3 different types ofio.EOF
in procedure loops).SQLEXCEPTION
signal handling, which will trigger for any error type (other than io.EOF) that bubbles up during aBeginEndIter
's execution.re: Add support for handlers dolthub/dolt#7454
Another thing I noticed is that some of our tests return nil for empty stored procedures when mysql returns
ERROR 1329 (02000): No data - zero rows fetched, selected, or processed
. https://github.com/dolthub/dolt/issues/newClosed Issues