opt, sql: fix type inference of TypeCheck for subqueries #37578
Conversation
|
This change is |
There was a problem hiding this comment.
Nice fix!
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis, @justinj, @RaduBerinde, and @rytaft)
pkg/sql/logictest/testdata/logic_test/subquery-opt, line 21 at r1 (raw file):
query ITIIIIIIT SELECT t.oid, t.typname, t.typsend, t.typreceive, t.typoutput, t.typinput, t.typelem, coalesce(r.rngsubtype, 0), ARRAY (
Is this array needed? (I expect the problem to come from the array below?)
pkg/sql/logictest/testdata/logic_test/subquery-opt, line 28 at r1 (raw file):
) FROM pg_type AS t LEFT JOIN pg_range AS r ON r.rngtypid = t.oid
do we need this join to repro?
pkg/sql/opt/optbuilder/subquery.go, line 61 at r1 (raw file):
// number of columns and is used when the normal type checking machinery will // verify that the correct number of columns is returned. desiredColumns int
[nit] numDesiredColumns or desiredNumColumns
pkg/sql/sem/tree/type_check.go, line 1740 at r1 (raw file):
desired := types.MakeTuple([]types.T{*typ}) typedRight, err := foldedRight.TypeCheck(ctx, desired) if switched {
How is this possible with IN? (if it was, seems like we should be doing this after the call below)
Prior to this commit, the optimizer was not correctly inferring the types of
columns in subqueries for expressions of the form `scalar IN (subquery)`.
This was due to two problems which have now been fixed:
1. The subquery was built as a relational expression before the desired types
were known. Now the subquery build is delayed until TypeCheck is called for
the first time.
2. For subqueries on the right side of an IN expression, the desired type
passed into TypeCheck was AnyTuple. This resulted in an error later on in
typeCheckSubqueryWithIn, which checks to make sure the type of the subquery
is tuple{T} where T is the type of the left expression. Now the desired
type passed into TypeCheck is tuple{T}.
Note that this commit only fixes type inference for the optimizer. It is still
broken in the heuristic planner.
Fixes cockroachdb#37263
Fixes cockroachdb#14554
Release note (bug fix): Fixed type inference of columns in subqueries for
some expressions of the form `scalar IN (subquery)`.
There was a problem hiding this comment.
TFTR!
Reviewable status:
pkg/sql/logictest/testdata/logic_test/subquery-opt, line 21 at r1 (raw file):
Previously, RaduBerinde wrote…
Is this array needed? (I expect the problem to come from the array below?)
Nope, I had just copied the query directly from the issue. Removed.
pkg/sql/logictest/testdata/logic_test/subquery-opt, line 28 at r1 (raw file):
Previously, RaduBerinde wrote…
do we need this join to repro?
Nope, removed.
pkg/sql/opt/optbuilder/subquery.go, line 61 at r1 (raw file):
Previously, RaduBerinde wrote…
[nit] numDesiredColumns or desiredNumColumns
Done.
pkg/sql/sem/tree/type_check.go, line 1740 at r1 (raw file):
Previously, RaduBerinde wrote…
How is this possible with IN? (if it was, seems like we should be doing this after the call below)
Good point - it's not possible. Removed.
There was a problem hiding this comment.
Reviewable status:
|
bors r+ |
37506: storage: reconcile manual splitting with automatic merging r=jeffrey-xiao a=jeffrey-xiao Follows the steps outlined in #37487 to reconcile manual splitting with automatic merging. This PR includes the changes needed at the storage layer. The sticky bit indicating that a range is manually split is added to the range descriptor. 37558: docs/tla-plus: add timestamp refreshes to ParallelCommits spec r=nvanbenschoten a=nvanbenschoten This commit adds transaction timestamp refreshes to the PlusCal model for parallel commits. This allows the committing transaction to bump its timestamp without a required epoch bump. This completes the parallel commits formal specification. 37578: opt, sql: fix type inference of TypeCheck for subqueries r=rytaft a=rytaft Prior to this commit, the optimizer was not correctly inferring the types of columns in subqueries for expressions of the form `scalar IN (subquery)`. This was due to two problems which have now been fixed: 1. The subquery was built as a relational expression before the desired types were known. Now the subquery build is delayed until `TypeCheck` is called for the first time. 2. For subqueries on the right side of an `IN` expression, the desired type passed into `TypeCheck` was `AnyTuple`. This resulted in an error later on in `typeCheckSubqueryWithIn`, which checks to make sure the type of the subquery is `tuple{T}` where `T` is the type of the left expression. Now the desired type passed into `TypeCheck` is `tuple{T}`. Note that this commit only fixes type inference for the optimizer. It is still broken in the heuristic planner. Fixes #37263 Fixes #14554 Release note (bug fix): Fixed type inference of columns in subqueries for some expressions of the form `scalar IN (subquery)`. Co-authored-by: Jeffrey Xiao <[email protected]> Co-authored-by: Nathan VanBenschoten <[email protected]> Co-authored-by: Rebecca Taft <[email protected]>
Build succeeded |
Prior to this commit, the optimizer was not correctly inferring the types of
columns in subqueries for expressions of the form
scalar IN (subquery).This was due to two problems which have now been fixed:
The subquery was built as a relational expression before the desired types
were known. Now the subquery build is delayed until
TypeCheckis called forthe first time.
For subqueries on the right side of an
INexpression, the desired typepassed into
TypeCheckwasAnyTuple. This resulted in an error later on intypeCheckSubqueryWithIn, which checks to make sure the type of the subqueryis
tuple{T}whereTis the type of the left expression. Now the desiredtype passed into
TypeCheckistuple{T}.Note that this commit only fixes type inference for the optimizer. It is still
broken in the heuristic planner.
Fixes #37263
Fixes #14554
Release note (bug fix): Fixed type inference of columns in subqueries for
some expressions of the form
scalar IN (subquery).