Support SubQueries interpretation as expressions
Summarize the changes
Support SubQueries as expressions. Previously they were supported only as a part of IN
or EXISTS
operators.
After this patch they can be used as a scalar expressions too.
Closes:
Ideologically unrelated but closes too:
Picodata follow-up: picodata!1229 (closed)
Ensure that
-
New code is covered by unit and integration tests. -
Related issues would be automatically closed with gitlab's closing pattern ( Closes #1, #2
). -
Public modules are documented (check the rendered version withcargo doc --open
). -
(if PEST grammar is changed) EBNF grammar reflects these changes (check the result with railroad diagram generator.
Next steps
- Cherry-pick to: none
- Update sbroad submodule in picodata/picodata.
Edited by Emir Vildanov
Merge request reports
Activity
- Resolved by Emir Vildanov
TODO (need help): why in case of
SELECT ... FROM (VALUES ...)
we get typesany
? Can it be fixed?
mentioned in issue #750 (closed)
added 26 commits
-
fac40d42...c1a1e7a2 - 21 commits from branch
main
- 66316700 - feat: support additional SubQuery children for any relational operator,...
- 68f20b91 - feat: fix tests
- eb6d1c05 - feat: add Copy to Type enum
- 519c244a - feat: implement logic of VALUES materialization on router, types checking and casting
- c35905a2 - feat: small fixed after rebase
Toggle commit list-
fac40d42...c1a1e7a2 - 21 commits from branch
mentioned in issue #683 (closed)
added 1 commit
- ed6614be - feat: support additional SubQuery children for any relational operator,...
added 1 commit
- 9877fa7d - feat: support additional SubQuery children for any relational operator,...
Please register or sign in to reply