exec: fix a bug with ordinality #39302
Conversation
|
This change is |
There was a problem hiding this comment.
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @jordanlewis, @rafiss, and @yuzefovich)
pkg/sql/logictest/testdata/logic_test/ordinality, line 79 at r1 (raw file):
# indices is done correctly. statement ok SET vectorize=experimental_on
Adding these everywhere will quickly become unmaintainable. Can we add a vec config to this file instead?
Ordinality operator was assuming that it's output column is always the last one which is incorrect when other column-appending operators are present. Release note: None
yuzefovich
force-pushed
the
exec-ordinality
branch
from
d863a85 to
5e224ec
Compare
There was a problem hiding this comment.
Reviewable status:
pkg/sql/logictest/testdata/logic_test/ordinality, line 79 at r1 (raw file):
Previously, jordanlewis (Jordan Lewis) wrote…
Adding these everywhere will quickly become unmaintainable. Can we add a
vecconfig to this file instead?
Good point, done.
There was a problem hiding this comment.
thanks for finding this!
Reviewed 1 of 2 files at r1, 1 of 1 files at r2.
Reviewable status:
|
Np! TFTRs! bors r+ |
39302: exec: fix a bug with ordinality r=yuzefovich a=yuzefovich Ordinality operator was assuming that it's output column is always the last one which is incorrect when other column-appending operators are present. Release note: None Co-authored-by: Yahor Yuzefovich <[email protected]>
Build succeeded |
Ordinality operator was assuming that it's output column is always
the last one which is incorrect when other column-appending operators
are present.
Release note: None